Building management system with timeseries processing

ABSTRACT

A building management system (BMS) includes building equipment configured to provide raw data samples of data points in the BMS, a data collector configured to generate raw data timeseries including raw data samples from the building equipment, and a timeseries processing engine. The timeseries processing engine is configured to identify an initial timeseries processing workflow that applies to the raw data timeseries, identify other data timeseries required as inputs to the initial timeseries processing workflow, and generate an enriched timeseries processing workflow that includes the initial timeseries processing workflow, the raw data timeseries, and the other data timeseries. The timeseries processing engine is configured to execute the enriched timeseries processing workflow to generate a derived data timeseries. The BMS further includes a timeseries storage interface configured to store the raw data timeseries and the derived data timeseries in a timeseries database.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/644,581 filed Jul. 7, 2017, which claims the benefit of and priorityto U.S. Provisional Patent Application No. 62/457,654 filed Feb. 10,2017. The entire disclosure of each of these patent applications isincorporated by reference herein.

BACKGROUND

The present disclosure relates generally to the field of buildingmanagement systems. A building management system (BMS) is, in general, asystem of devices configured to control, monitor, and manage equipmentin or around a building or building area. A BMS can include, forexample, a HVAC system, a security system, a lighting system, a firealerting system, any other system that is capable of managing buildingfunctions or devices, or any combination thereof.

A BMS can collect data from sensors and other types of buildingequipment. Data can be collected over time and combined into streams oftimeseries data. Each sample of the timeseries data can include atimestamp and a data value. Some BMSs store raw timeseries data in arelational database without significant organization or processing atthe time of data collection. Applications that consume the timeseriesdata are typically responsible for retrieving the raw timeseries datafrom the database and generating views of the timeseries data that canbe presented via a chart, graph, or other user interface. Theseprocessing steps are typically performed in response to a request forthe timeseries data, which can significantly delay data presentation atquery time.

SUMMARY

One implementation of the present disclosure is a building managementsystem (BMS). The BMS includes building equipment configured to provideraw data samples of one or more data points in the BMS, a data collectorconfigured to collect the raw data samples from the building equipmentand generate one or more raw data timeseries including a plurality ofthe raw data samples, and a timeseries processing engine. The timeseriesprocessing engine is configured to identify an initial timeseriesprocessing workflow that applies to the raw data timeseries. The initialtimeseries processing workflow includes a predefined sequence oftimeseries processing operations. The timeseries processing engine isconfigured to identify one or more other data timeseries required asinputs to the initial timeseries processing workflow and generate anenriched timeseries processing workflow that includes the initialtimeseries processing workflow, the raw data timeseries, and the otherdata timeseries. The timeseries processing engine is configured toexecute the enriched timeseries processing workflow to generate one ormore derived data timeseries from the raw data timeseries and the one ormore other data timeseries. The BMS further includes a timeseriesstorage interface configured to store the raw data timeseries and thederived data timeseries in a timeseries database.

In some embodiments, the timeseries processing engine is configured toidentify and obtain samples of the raw data timeseries and the otherdata timeseries required to perform the timeseries processing operationsand generate the enriched timeseries processing workflow comprising theidentified samples of the raw data timeseries and the other datatimeseries.

In some embodiments, the timeseries processing engine is configured todetermine a time window based on an aggregation period specified by thetimeseries processing operations and obtain samples of the raw datatimeseries and the other data timeseries that have timestamps within thetime window. In some embodiments, the timeseries processing engine isconfigured to determine the time window based on a timestamp of the rawdata samples and a duration of the aggregation period specified by thetimeseries processing operations.

In some embodiments, the timeseries processing engine is configured totag each of the timeseries processing operations in the enrichedtimeseries processing workflow with an indication of an execution engineand execute each timeseries processing operation using the indicatedexecution engine.

In some embodiments, the timeseries processing engine is configured toaccept a post-sample request associated with the raw data timeseries andexecute the post-sample request in response to obtaining one or more newsamples of the raw data timeseries.

In some embodiments, the initial timeseries processing workflow includesan indication of one or more input timeseries to which the initialtimeseries processing workflow applies, the predefined sequence oftimeseries processing operations, and an indication of one or morederived data timeseries generated by applying the predefined sequence oftimeseries processing operations to the input timeseries.

In some embodiments, the input timeseries include at least one of theone or more raw data timeseries generated by the data collector, or theone or more derived data timeseries generated by the timeseriesprocessing engine.

In some embodiments, the initial timeseries processing workflow includesa directed acyclic graph visually representing the predefined sequenceof timeseries operations in the initial timeseries processing workflow.In some embodiments, the directed acyclic graph includes one or moreinput blocks representing one or more input timeseries to which theinitial timeseries processing workflow applies, one or more functionalblocks representing the predefined sequence of timeseries processingoperations in the initial timeseries processing workflow, and one ormore output blocks representing one or more derived data timeseriesgenerated by applying the predefined sequence of timeseries processingoperations to the input timeseries.

Another implementation of the present disclosure is a method forprocessing timeseries data in a building management system. The methodincludes operating building equipment to generate raw data samples ofone or more data points in the building management system, collectingthe raw data samples from the building equipment, generating one or moreraw data timeseries that include a plurality of the raw data samples,and identifying an initial timeseries processing workflow that appliesto the raw data timeseries. The initial timeseries processing workflowincludes a predefined sequence of timeseries processing operations. Themethod further includes identifying one or more other data timeseriesrequired as inputs to the initial timeseries processing workflow andgenerating an enriched timeseries processing workflow comprising theinitial timeseries processing workflow, the raw data timeseries, and theother data timeseries. The method includes executing the enrichedtimeseries processing workflow to generate one or more derived datatimeseries from the raw data timeseries and the one or more other datatimeseries and storing the raw data timeseries and the derived datatimeseries in a timeseries database.

In some embodiments, the method includes identifying and obtainingsamples of the raw data timeseries and the other data timeseriesrequired to perform the timeseries processing operations and generatingthe enriched timeseries processing workflow comprising the identifiedsamples of the raw data timeseries and the other data timeseries.

In some embodiments, the method includes determining a time window basedon an aggregation period specified by the timeseries processingoperations and obtaining samples of the raw data timeseries and theother data timeseries that have timestamps within the time window.

In some embodiments, the method includes determining the time windowbased on a timestamp of the raw data samples and a duration of theaggregation period specified by the timeseries processing operations.

In some embodiments, the method includes tagging each of the timeseriesprocessing operations in the enriched timeseries processing workflowwith an indication of an execution engine and executing each timeseriesprocessing operation using the indicated execution engine.

In some embodiments, the method includes accepting a post-sample requestassociated with the raw data timeseries and executing the post-samplerequest in response to obtaining one or more new samples of the raw datatimeseries.

In some embodiments, the initial timeseries processing workflow includesan indication of one or more input timeseries to which the initialtimeseries processing workflow applies, the predefined sequence oftimeseries processing operations, and an indication of one or morederived data timeseries generated by applying the predefined sequence oftimeseries processing operations to the input timeseries. In someembodiments, the input timeseries include at least one of the one ormore raw data timeseries or the one or more derived data timeseries.

In some embodiments, the initial timeseries processing workflow includesa directed acyclic graph visually representing the predefined sequenceof timeseries operations in the initial timeseries processing workflow.In some embodiments, the directed acyclic graph includes one or moreinput blocks representing one or more input timeseries to which theinitial timeseries processing workflow applies, one or more functionalblocks representing the predefined sequence of timeseries processingoperations in the initial timeseries processing workflow, and one ormore output blocks representing one or more derived data timeseriesgenerated by applying the predefined sequence of timeseries processingoperations to the input timeseries.

Those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the devices and/orprocesses described herein, as defined solely by the claims, will becomeapparent in the detailed description set forth herein and taken inconjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drawing of a building equipped with a building managementsystem (BMS) and a HVAC system, according to some embodiments.

FIG. 2 is a schematic of a waterside system which can be used as part ofthe HVAC system of FIG. 1, according to some embodiments.

FIG. 3 is a block diagram of an airside system which can be used as partof the HVAC system of FIG. 1, according to some embodiments.

FIG. 4 is a block diagram of a BMS which can be used in the building ofFIG. 1, according to some embodiments.

FIG. 5 is a block diagram of another BMS which can be used in thebuilding of FIG. 1, including a data collector, data platform services,applications, and a dashboard layout generator, according to someembodiments.

FIG. 6 is a block diagram of a timeseries service which can beimplemented as some of the data platform services shown in FIG. 5,according to some embodiments.

FIG. 7A is a block diagram illustrating an aggregation technique whichcan be used by the sample aggregator shown in FIG. 6 to aggregate rawdata samples, according to some embodiments.

FIG. 7B is a data table which can be used to store raw data timeseriesand a variety of derived data timeseries which can be generated by thetimeseries service of FIG. 6, according to some embodiments.

FIG. 8 is a drawing of several timeseries illustrating thesynchronization of data samples which can be performed by the dataaggregator shown in FIG. 6, according to some embodiments.

FIG. 9A is a flow diagram illustrating the creation and storage of afault detection timeseries which can be performed by the fault detectorshown in FIG. 6, according to some embodiments.

FIG. 9B is a data table which can be used to store the raw datatimeseries and the fault detection timeseries, according to someembodiments.

FIG. 9C is a data table which can be used to store states assigned tosamples of a data timeseries, according to some embodiments.

FIG. 9D is a data table including various events generated based on theassigned states shown in the table of FIG. 9C, according to someembodiments.

FIG. 9E is a data table including a timeseries of data values andassigned states, according to some embodiments.

FIG. 9F is a data table including events which can be generated based ona first portion of the data table of FIG. 9E, according to someembodiments.

FIG. 9G is a data table illustrating updates to the events shown in thedata table of FIG. 9F which can be made upon receiving a new sample ofthe timeseries shown in FIG. 9E, according to some embodiments.

FIG. 9H is another data table illustrating updates to the events shownin the data table of FIG. 9G which can be made upon receiving a newsample of the timeseries shown in FIG. 9E, according to someembodiments.

FIG. 9I is a data table including a timeseries of data values andassigned states in which one of the data samples is received out oforder, according to some embodiments.

FIG. 9J is a data table including events which can be generated based ona first portion of the data table of FIG. 9I, according to someembodiments.

FIG. 9K is a data table illustrating updates to the events shown in thedata table of FIG. 9J which can be made upon receiving a new sample ofthe timeseries shown in FIG. 9I, according to some embodiments.

FIG. 9L is another data table illustrating updates to the events shownin the data table of FIG. 9K which can be made upon receiving a newsample of the timeseries shown in FIG. 9I, according to someembodiments.

FIG. 9M is another data table illustrating updates to the events shownin the data table of FIG. 9L which can be made upon receiving a newsample of the timeseries shown in FIG. 9I, according to someembodiments.

FIG. 9N is another data table including a timeseries of data values andassigned states in which one of the data samples is received out oforder, according to some embodiments.

FIG. 9O is a data table including events which can be generated based ona first portion of the data table of FIG. 9N, according to someembodiments.

FIG. 9P is a data table illustrating updates to the events shown in thedata table of FIG. 9O which can be made upon receiving a new sample ofthe timeseries shown in FIG. 9N, according to some embodiments.

FIG. 9Q is another data table illustrating updates to the events shownin the data table of FIG. 9P which can be made upon receiving a newsample of the timeseries shown in FIG. 9N, according to someembodiments.

FIG. 9R is another data table illustrating updates to the events shownin the data table of FIG. 9P which can be made upon receiving a newsample of the timeseries shown in FIG. 9N, according to someembodiments.

FIG. 9S is a data table including a timeseries of data values andassigned states in which several of the data samples are received out oforder, according to some embodiments.

FIG. 9T is a data table including events which can be generated based ona first portion of the data table of FIG. 9S, according to someembodiments.

FIG. 9U is a data table illustrating updates to the events shown in thedata table of FIG. 9T which can be made upon receiving a new sample ofthe timeseries shown in FIG. 9S, according to some embodiments.

FIG. 9V is another data table illustrating updates to the events shownin the data table of FIG. 9U which can be made upon receiving a newsample of the timeseries shown in FIG. 9S, according to someembodiments.

FIG. 9W is another data table including a timeseries of data values andassigned states in which several of the data samples are received out oforder, according to some embodiments.

FIG. 9X is a data table illustrating updates to the events shown in thedata table of FIG. 9V which can be made upon receiving a new sample ofthe timeseries shown in FIG. 9W, according to some embodiments.

FIG. 9Y is another data table illustrating updates to the events shownin the data table of FIG. 9X which can be made upon receiving a newsample of the timeseries shown in FIG. 9W, according to someembodiments.

FIG. 9Z is a flowchart of a process for generating and updating eventsand eventseries, according to some embodiments.

FIG. 10A is a directed acyclic graph (DAG) which can be generated by theDAG generator of FIG. 6, according to some embodiments.

FIG. 10B is a code snippet which can be automatically generated by theDAG generator of FIG. 6 based on the DAG, according to some embodiments.

FIG. 11A is an entity graph illustrating relationships between anorganization, a space, a system, a point, and a timeseries, which can beused by the data collector of FIG. 5, according to some embodiments.

FIG. 11B is an example of an entity graph for a particular buildingmanagement system according to some embodiments.

FIG. 12 is an object relationship diagram illustrating relationshipsbetween an entity template, a point, a timeseries, and a data sample,which can be used by the data collector of FIG. 5 and the timeseriesservice of FIG. 6, according to some embodiments.

FIG. 13A is a block diagram illustrating a timeseries processingworkflow which can be performed by the timeseries service of FIGS. 5-6,according to some embodiments.

FIG. 13B is a flowchart of a process which can be performed by theworkflow manager of FIG. 13A, according to some embodiments.

FIG. 14 is a block diagram illustrating a silo configured IoTenvironment 1400, according to some embodiments.

FIG. 15 is a block diagram illustrating a decentralized IoT environment,according to some embodiments.

FIG. 16 is a block diagram illustrating a multi-modal data processingservice, according to some embodiments.

FIG. 17 is an example user interface providing a view of multi-modaldata, according to some embodiments.

FIG. 18 is a block diagram illustrating an IoT application storagetopology, according to some embodiments.

FIG. 19 is a block diagram illustrating a data scheme associated with apiece of equipment in a BMS, according to some embodiments.

FIG. 20 is a data map illustrating data mapping between entity/documentstores and streamed data (e.g. telemetry data) stores, according to someembodiments.

FIG. 21 is a block diagram illustrating a reference abstractionarchitecture, according to some embodiments.

FIG. 22 is a flow chart illustrating a process for performing unifiedstream processing, according to some embodiments.

DETAILED DESCRIPTION

Overview

Referring generally to the FIGURES, a building management system (BMS)with declarative views of timeseries data is shown, according to variousembodiments. The BMS is configured to collect data samples from buildingequipment (e.g., sensors, controllable devices, building subsystems,etc.) and generate raw timeseries data from the data samples. The BMScan process the raw timeseries data using a variety of data platformservices to generate derived timeseries data (e.g., data rolluptimeseries, virtual point timeseries, fault detection timeseries, etc.).The derived timeseries data can be provided to various applicationsand/or stored in local or hosted storage. In some embodiments, the BMSincludes three different layers that separate (1) data collection, (2)data storage, retrieval, and analysis, and (3) data visualization. Thisallows the BMS to support a variety of applications that use the derivedtimeseries data and allows new applications to reuse the infrastructureprovided by the data platform services.

In some embodiments, the BMS includes a data collector configured tocollect raw data samples from the building equipment. The data collectorcan generate a raw data timeseries including a plurality of the raw datasamples and store the raw data timeseries in the timeseries database. Insome embodiments, the data collector stores each of the raw data sampleswith a timestamp. The timestamp can include a local time indicating thetime at which the raw data sample was collected in whichever time zonethe raw data sample was collected. The timestamp can also include a timeoffset indicating a difference between the local time and universaltime. The combination of the local timestamp and the offset provides aunique timestamp across daylight saving time boundaries. This allows anapplication using the timeseries data to display the timeseries data inlocal time without first converting from universal time. The combinationof the local timestamp and the offset also provides enough informationto convert the local timestamp to universal time without needing to lookup a schedule of when daylight savings time occurs.

In some embodiments, the data platform services include a sampleaggregator. The sample aggregator can aggregate predefined intervals ofthe raw timeseries data (e.g., quarter-hourly intervals, hourlyintervals, daily intervals, monthly intervals, etc.) to generate newderived timeseries of the aggregated values. These derived timeseriescan be referred to as “data rollups” since they are condensed versionsof the raw timeseries data. The data rollups generated by the dataaggregator provide an efficient mechanism for various applications toquery the timeseries data. For example, the applications can constructvisualizations of the timeseries data (e.g., charts, graphs, etc.) usingthe pre-aggregated data rollups instead of the raw timeseries data. Thisallows the applications to simply retrieve and present thepre-aggregated data rollups without requiring applications to perform anaggregation in response to the query. Since the data rollups arepre-aggregated, the applications can present the data rollups quicklyand efficiently without requiring additional processing at query time togenerate aggregated timeseries values.

In some embodiments, the data platform services include a virtual pointcalculator. The virtual point calculator can calculate virtual pointsbased on the raw timeseries data and/or the derived timeseries data.Virtual points can be calculated by applying any of a variety ofmathematical operations (e.g., addition, subtraction, multiplication,division, etc.) or functions (e.g., average value, maximum value,minimum value, thermodynamic functions, linear functions, nonlinearfunctions, etc.) to the actual data points represented by the timeseriesdata. For example, the virtual point calculator can calculate a virtualdata point (pointID₃) by adding two or more actual data points (pointID₁and pointID₂) (e.g., pointID₃=pointID₁+pointID₂). As another example,the virtual point calculator can calculate an enthalpy data point(pointID₄) based on a measured temperature data point (pointID₅) and ameasured pressure data point (pointID₆) (e.g.,pointID₄=enthalpy(pointID₅, pointID₆)). The virtual data points can bestored as derived timeseries data.

Applications can access and use the virtual data points in the samemanner as the actual data points. The applications do not need to knowwhether a data point is an actual data point or a virtual data pointsince both types of data points can be stored as derived timeseries dataand can be handled in the same manner by the applications. In someembodiments, the derived timeseries data are stored with attributesdesignating each data point as either a virtual data point or an actualdata point. Such attributes allow the applications to identify whether agiven timeseries represents a virtual data point or an actual datapoint, even though both types of data points can be handled in the samemanner by the applications.

In some embodiments, the data platform services include a fault detectorconfigured to analyze the timeseries data to detect faults. Faultdetection can be performed by applying a set of fault detection rules tothe timeseries data to determine whether a fault is detected at eachinterval of the timeseries. Fault detections can be stored as derivedtimeseries data. For example, new timeseries can be generated with datavalues that indicate whether a fault was detected at each interval ofthe timeseries. The time series of fault detections can be stored alongwith the raw timeseries data and/or derived timeseries data in local orhosted data storage. These and other features of the building managementsystem are described in greater detail below.

Building Management System and HVAC System

Referring now to FIGS. 1-4, an exemplary building management system(BMS) and HVAC system in which the systems and methods of the presentdisclosure can be implemented are shown, according to an exemplaryembodiment. Referring particularly to FIG. 1, a perspective view of abuilding 10 is shown. Building 10 is served by a BMS. A BMS is, ingeneral, a system of devices configured to control, monitor, and manageequipment in or around a building or building area. A BMS can include,for example, a HVAC system, a security system, a lighting system, a firealerting system, any other system that is capable of managing buildingfunctions or devices, or any combination thereof.

The BMS that serves building 10 includes an HVAC system 100. HVAC system100 can include a plurality of HVAC devices (e.g., heaters, chillers,air handling units, pumps, fans, thermal energy storage, etc.)configured to provide heating, cooling, ventilation, or other servicesfor building 10. For example, HVAC system 100 is shown to include awaterside system 120 and an airside system 130. Waterside system 120 canprovide a heated or chilled fluid to an air handling unit of airsidesystem 130. Airside system 130 can use the heated or chilled fluid toheat or cool an airflow provided to building 10. An exemplary watersidesystem and airside system which can be used in HVAC system 100 aredescribed in greater detail with reference to FIGS. 2-3.

HVAC system 100 is shown to include a chiller 102, a boiler 104, and arooftop air handling unit (AHU) 106. Waterside system 120 can use boiler104 and chiller 102 to heat or cool a working fluid (e.g., water,glycol, etc.) and can circulate the working fluid to AHU 106. In variousembodiments, the HVAC devices of waterside system 120 can be located inor around building 10 (as shown in FIG. 1) or at an offsite locationsuch as a central plant (e.g., a chiller plant, a steam plant, a heatplant, etc.). The working fluid can be heated in boiler 104 or cooled inchiller 102, depending on whether heating or cooling is required inbuilding 10. Boiler 104 can add heat to the circulated fluid, forexample, by burning a combustible material (e.g., natural gas) or usingan electric heating element. Chiller 102 can place the circulated fluidin a heat exchange relationship with another fluid (e.g., a refrigerant)in a heat exchanger (e.g., an evaporator) to absorb heat from thecirculated fluid. The working fluid from chiller 102 and/or boiler 104can be transported to AHU 106 via piping 108.

AHU 106 can place the working fluid in a heat exchange relationship withan airflow passing through AHU 106 (e.g., via one or more stages ofcooling coils and/or heating coils). The airflow can be, for example,outside air, return air from within building 10, or a combination ofboth. AHU 106 can transfer heat between the airflow and the workingfluid to provide heating or cooling for the airflow. For example, AHU106 can include one or more fans or blowers configured to pass theairflow over or through a heat exchanger containing the working fluid.The working fluid can then return to chiller 102 or boiler 104 viapiping 110.

Airside system 130 can deliver the airflow supplied by AHU 106 (i.e.,the supply airflow) to building 10 via air supply ducts 112 and canprovide return air from building 10 to AHU 106 via air return ducts 114.In some embodiments, airside system 130 includes multiple variable airvolume (VAV) units 116. For example, airside system 130 is shown toinclude a separate VAV unit 116 on each floor or zone of building 10.VAV units 116 can include dampers or other flow control elements thatcan be operated to control an amount of the supply airflow provided toindividual zones of building 10. In other embodiments, airside system130 delivers the supply airflow into one or more zones of building 10(e.g., via supply ducts 112) without using intermediate VAV units 116 orother flow control elements. AHU 106 can include various sensors (e.g.,temperature sensors, pressure sensors, etc.) configured to measureattributes of the supply airflow. AHU 106 can receive input from sensorslocated within AHU 106 and/or within the building zone and can adjustthe flow rate, temperature, or other attributes of the supply airflowthrough AHU 106 to achieve setpoint conditions for the building zone.

Referring now to FIG. 2, a block diagram of a waterside system 200 isshown, according to an exemplary embodiment. In various embodiments,waterside system 200 can supplement or replace waterside system 120 inHVAC system 100 or can be implemented separate from HVAC system 100.When implemented in HVAC system 100, waterside system 200 can include asubset of the HVAC devices in HVAC system 100 (e.g., boiler 104, chiller102, pumps, valves, etc.) and can operate to supply a heated or chilledfluid to AHU 106. The HVAC devices of waterside system 200 can belocated within building 10 (e.g., as components of waterside system 120)or at an offsite location such as a central plant.

In FIG. 2, waterside system 200 is shown as a central plant having aplurality of subplants 202-212. Subplants 202-212 are shown to include aheater subplant 202, a heat recovery chiller subplant 204, a chillersubplant 206, a cooling tower subplant 208, a hot thermal energy storage(TES) subplant 210, and a cold thermal energy storage (TES) subplant212. Subplants 202-212 consume resources (e.g., water, natural gas,electricity, etc.) from utilities to serve the thermal energy loads(e.g., hot water, cold water, heating, cooling, etc.) of a building orcampus. For example, heater subplant 202 can be configured to heat waterin a hot water loop 214 that circulates the hot water between heatersubplant 202 and building 10. Chiller subplant 206 can be configured tochill water in a cold water loop 216 that circulates the cold waterbetween chiller subplant 206 building 10. Heat recovery chiller subplant204 can be configured to transfer heat from cold water loop 216 to hotwater loop 214 to provide additional heating for the hot water andadditional cooling for the cold water. Condenser water loop 218 canabsorb heat from the cold water in chiller subplant 206 and reject theabsorbed heat in cooling tower subplant 208 or transfer the absorbedheat to hot water loop 214. Hot TES subplant 210 and cold TES subplant212 can store hot and cold thermal energy, respectively, for subsequentuse.

Hot water loop 214 and cold water loop 216 can deliver the heated and/orchilled water to air handlers located on the rooftop of building 10(e.g., AHU 106) or to individual floors or zones of building 10 (e.g.,VAV units 116). The air handlers push air past heat exchangers (e.g.,heating coils or cooling coils) through which the water flows to provideheating or cooling for the air. The heated or cooled air can bedelivered to individual zones of building 10 to serve the thermal energyloads of building 10. The water then returns to subplants 202-212 toreceive further heating or cooling.

Although subplants 202-212 are shown and described as heating andcooling water for circulation to a building, it is understood that anyother type of working fluid (e.g., glycol, CO2, etc.) can be used inplace of or in addition to water to serve the thermal energy loads. Inother embodiments, subplants 202-212 can provide heating and/or coolingdirectly to the building or campus without requiring an intermediateheat transfer fluid. These and other variations to waterside system 200are within the teachings of the present invention.

Each of subplants 202-212 can include a variety of equipment configuredto facilitate the functions of the subplant. For example, heatersubplant 202 is shown to include a plurality of heating elements 220(e.g., boilers, electric heaters, etc.) configured to add heat to thehot water in hot water loop 214. Heater subplant 202 is also shown toinclude several pumps 222 and 224 configured to circulate the hot waterin hot water loop 214 and to control the flow rate of the hot waterthrough individual heating elements 220. Chiller subplant 206 is shownto include a plurality of chillers 232 configured to remove heat fromthe cold water in cold water loop 216. Chiller subplant 206 is alsoshown to include several pumps 234 and 236 configured to circulate thecold water in cold water loop 216 and to control the flow rate of thecold water through individual chillers 232.

Heat recovery chiller subplant 204 is shown to include a plurality ofheat recovery heat exchangers 226 (e.g., refrigeration circuits)configured to transfer heat from cold water loop 216 to hot water loop214. Heat recovery chiller subplant 204 is also shown to include severalpumps 228 and 230 configured to circulate the hot water and/or coldwater through heat recovery heat exchangers 226 and to control the flowrate of the water through individual heat recovery heat exchangers 226.Cooling tower subplant 208 is shown to include a plurality of coolingtowers 238 configured to remove heat from the condenser water incondenser water loop 218. Cooling tower subplant 208 is also shown toinclude several pumps 240 configured to circulate the condenser water incondenser water loop 218 and to control the flow rate of the condenserwater through individual cooling towers 238.

Hot TES subplant 210 is shown to include a hot TES tank 242 configuredto store the hot water for later use. Hot TES subplant 210 can alsoinclude one or more pumps or valves configured to control the flow rateof the hot water into or out of hot TES tank 242. Cold TES subplant 212is shown to include cold TES tanks 244 configured to store the coldwater for later use. Cold TES subplant 212 can also include one or morepumps or valves configured to control the flow rate of the cold waterinto or out of cold TES tanks 244.

In some embodiments, one or more of the pumps in waterside system 200(e.g., pumps 222, 224, 228, 230, 234, 236, and/or 240) or pipelines inwaterside system 200 include an isolation valve associated therewith.Isolation valves can be integrated with the pumps or positioned upstreamor downstream of the pumps to control the fluid flows in watersidesystem 200. In various embodiments, waterside system 200 can includemore, fewer, or different types of devices and/or subplants based on theparticular configuration of waterside system 200 and the types of loadsserved by waterside system 200.

Referring now to FIG. 3, a block diagram of an airside system 300 isshown, according to an exemplary embodiment. In various embodiments,airside system 300 can supplement or replace airside system 130 in HVACsystem 100 or can be implemented separate from HVAC system 100. Whenimplemented in HVAC system 100, airside system 300 can include a subsetof the HVAC devices in HVAC system 100 (e.g., AHU 106, VAV units 116,ducts 112-114, fans, dampers, etc.) and can be located in or aroundbuilding 10. Airside system 300 can operate to heat or cool an airflowprovided to building 10 using a heated or chilled fluid provided bywaterside system 200.

In FIG. 3, airside system 300 is shown to include an economizer-type airhandling unit (AHU) 302. Economizer-type AHUs vary the amount of outsideair and return air used by the air handling unit for heating or cooling.For example, AHU 302 can receive return air 304 from building zone 306via return air duct 308 and can deliver supply air 310 to building zone306 via supply air duct 312. In some embodiments, AHU 302 is a rooftopunit located on the roof of building 10 (e.g., AHU 106 as shown inFIG. 1) or otherwise positioned to receive both return air 304 andoutside air 314. AHU 302 can be configured to operate exhaust air damper316, mixing damper 318, and outside air damper 320 to control an amountof outside air 314 and return air 304 that combine to form supply air310. Any return air 304 that does not pass through mixing damper 318 canbe exhausted from AHU 302 through exhaust damper 316 as exhaust air 322.

Each of dampers 316-320 can be operated by an actuator. For example,exhaust air damper 316 can be operated by actuator 324, mixing damper318 can be operated by actuator 326, and outside air damper 320 can beoperated by actuator 328. Actuators 324-328 can communicate with an AHUcontroller 330 via a communications link 332. Actuators 324-328 canreceive control signals from AHU controller 330 and can provide feedbacksignals to AHU controller 330. Feedback signals can include, forexample, an indication of a current actuator or damper position, anamount of torque or force exerted by the actuator, diagnosticinformation (e.g., results of diagnostic tests performed by actuators324-328), status information, commissioning information, configurationsettings, calibration data, and/or other types of information or datathat can be collected, stored, or used by actuators 324-328. AHUcontroller 330 can be an economizer controller configured to use one ormore control algorithms (e.g., state-based algorithms, extremum seekingcontrol (ESC) algorithms, proportional-integral (PI) control algorithms,proportional-integral-derivative (PID) control algorithms, modelpredictive control (MPC) algorithms, feedback control algorithms, etc.)to control actuators 324-328.

Still referring to FIG. 3, AHU 302 is shown to include a cooling coil334, a heating coil 336, and a fan 338 positioned within supply air duct312. Fan 338 can be configured to force supply air 310 through coolingcoil 334 and/or heating coil 336 and provide supply air 310 to buildingzone 306. AHU controller 330 can communicate with fan 338 viacommunications link 340 to control a flow rate of supply air 310. Insome embodiments, AHU controller 330 controls an amount of heating orcooling applied to supply air 310 by modulating a speed of fan 338.

Cooling coil 334 can receive a chilled fluid from waterside system 200(e.g., from cold water loop 216) via piping 342 and can return thechilled fluid to waterside system 200 via piping 344. Valve 346 can bepositioned along piping 342 or piping 344 to control a flow rate of thechilled fluid through cooling coil 334. In some embodiments, coolingcoil 334 includes multiple stages of cooling coils that can beindependently activated and deactivated (e.g., by AHU controller 330, byBMS controller 366, etc.) to modulate an amount of cooling applied tosupply air 310.

Heating coil 336 can receive a heated fluid from waterside system 200(e.g., from hot water loop 214) via piping 348 and can return the heatedfluid to waterside system 200 via piping 350. Valve 352 can bepositioned along piping 348 or piping 350 to control a flow rate of theheated fluid through heating coil 336. In some embodiments, heating coil336 includes multiple stages of heating coils that can be independentlyactivated and deactivated (e.g., by AHU controller 330, by BMScontroller 366, etc.) to modulate an amount of heating applied to supplyair 310.

Each of valves 346 and 352 can be controlled by an actuator. Forexample, valve 346 can be controlled by actuator 354 and valve 352 canbe controlled by actuator 356. Actuators 354-356 can communicate withAHU controller 330 via communications links 358-360. Actuators 354-356can receive control signals from AHU controller 330 and can providefeedback signals to controller 330. In some embodiments, AHU controller330 receives a measurement of the supply air temperature from atemperature sensor 362 positioned in supply air duct 312 (e.g.,downstream of cooling coil 334 and/or heating coil 336). AHU controller330 can also receive a measurement of the temperature of building zone306 from a temperature sensor 364 located in building zone 306.

In some embodiments, AHU controller 330 operates valves 346 and 352 viaactuators 354-356 to modulate an amount of heating or cooling providedto supply air 310 (e.g., to achieve a setpoint temperature for supplyair 310 or to maintain the temperature of supply air 310 within asetpoint temperature range). The positions of valves 346 and 352 affectthe amount of heating or cooling provided to supply air 310 by coolingcoil 334 or heating coil 336 and may correlate with the amount of energyconsumed to achieve a desired supply air temperature. AHU controller 330can control the temperature of supply air 310 and/or building zone 306by activating or deactivating coils 334-336, adjusting a speed of fan338, or a combination of both.

Still referring to FIG. 3, airside system 300 is shown to include abuilding management system (BMS) controller 366 and a client device 368.BMS controller 366 can include one or more computer systems (e.g.,servers, supervisory controllers, subsystem controllers, etc.) thatserve as system level controllers, application or data servers, headnodes, or master controllers for airside system 300, waterside system200, HVAC system 100, and/or other controllable systems that servebuilding 10. BMS controller 366 can communicate with multiple downstreambuilding systems or subsystems (e.g., HVAC system 100, a securitysystem, a lighting system, waterside system 200, etc.) via acommunications link 370 according to like or disparate protocols (e.g.,LON, BACnet, etc.). In various embodiments, AHU controller 330 and BMScontroller 366 can be separate (as shown in FIG. 3) or integrated. In anintegrated implementation, AHU controller 330 can be a software moduleconfigured for execution by a processor of BMS controller 366.

In some embodiments, AHU controller 330 receives information from BMScontroller 366 (e.g., commands, setpoints, operating boundaries, etc.)and provides information to BMS controller 366 (e.g., temperaturemeasurements, valve or actuator positions, operating statuses,diagnostics, etc.). For example, AHU controller 330 can provide BMScontroller 366 with temperature measurements from temperature sensors362-364, equipment on/off states, equipment operating capacities, and/orany other information that can be used by BMS controller 366 to monitoror control a variable state or condition within building zone 306.

Client device 368 can include one or more human-machine interfaces orclient interfaces (e.g., graphical user interfaces, reportinginterfaces, text-based computer interfaces, client-facing web services,web servers that provide pages to web clients, etc.) for controlling,viewing, or otherwise interacting with HVAC system 100, its subsystems,and/or devices. Client device 368 can be a computer workstation, aclient terminal, a remote or local interface, or any other type of userinterface device. Client device 368 can be a stationary terminal or amobile device. For example, client device 368 can be a desktop computer,a computer server with a user interface, a laptop computer, a tablet, asmartphone, a PDA, or any other type of mobile or non-mobile device.Client device 368 can communicate with BMS controller 366 and/or AHUcontroller 330 via communications link 372.

Referring now to FIG. 4, a block diagram of a building management system(BMS) 400 is shown, according to an exemplary embodiment. BMS 400 can beimplemented in building 10 to automatically monitor and control variousbuilding functions. BMS 400 is shown to include BMS controller 366 and aplurality of building subsystems 428. Building subsystems 428 are shownto include a building electrical subsystem 434, an informationcommunication technology (ICT) subsystem 436, a security subsystem 438,a HVAC subsystem 440, a lighting subsystem 442, a lift/escalatorssubsystem 432, and a fire safety subsystem 430. In various embodiments,building subsystems 428 can include fewer, additional, or alternativesubsystems. For example, building subsystems 428 can also oralternatively include a refrigeration subsystem, an advertising orsignage subsystem, a cooking subsystem, a vending subsystem, a printeror copy service subsystem, or any other type of building subsystem thatuses controllable equipment and/or sensors to monitor or controlbuilding 10. In some embodiments, building subsystems 428 includewaterside system 200 and/or airside system 300, as described withreference to FIGS. 2-3.

Each of building subsystems 428 can include any number of devices,controllers, and connections for completing its individual functions andcontrol activities. HVAC subsystem 440 can include many of the samecomponents as HVAC system 100, as described with reference to FIGS. 1-3.For example, HVAC subsystem 440 can include a chiller, a boiler, anynumber of air handling units, economizers, field controllers,supervisory controllers, actuators, temperature sensors, and otherdevices for controlling the temperature, humidity, airflow, or othervariable conditions within building 10. Lighting subsystem 442 caninclude any number of light fixtures, ballasts, lighting sensors,dimmers, or other devices configured to controllably adjust the amountof light provided to a building space. Security subsystem 438 caninclude occupancy sensors, video surveillance cameras, digital videorecorders, video processing servers, intrusion detection devices, accesscontrol devices and servers, or other security-related devices.

Still referring to FIG. 4, BMS controller 366 is shown to include acommunications interface 407 and a BMS interface 409. Interface 407 canfacilitate communications between BMS controller 366 and externalapplications (e.g., monitoring and reporting applications 422,enterprise control applications 426, remote systems and applications444, applications residing on client devices 448, etc.) for allowinguser control, monitoring, and adjustment to BMS controller 366 and/orsubsystems 428. Interface 407 can also facilitate communications betweenBMS controller 366 and client devices 448. BMS interface 409 canfacilitate communications between BMS controller 366 and buildingsubsystems 428 (e.g., HVAC, lighting security, lifts, powerdistribution, business, etc.).

Interfaces 407, 409 can be or include wired or wireless communicationsinterfaces (e.g., jacks, antennas, transmitters, receivers,transceivers, wire terminals, etc.) for conducting data communicationswith building subsystems 428 or other external systems or devices. Invarious embodiments, communications via interfaces 407, 409 can bedirect (e.g., local wired or wireless communications) or via acommunications network 446 (e.g., a WAN, the Internet, a cellularnetwork, etc.). For example, interfaces 407, 409 can include an Ethernetcard and port for sending and receiving data via an Ethernet-basedcommunications link or network. In another example, interfaces 407, 409can include a WiFi transceiver for communicating via a wirelesscommunications network. In another example, one or both of interfaces407, 409 can include cellular or mobile phone communicationstransceivers. In one embodiment, communications interface 407 is a powerline communications interface and BMS interface 409 is an Ethernetinterface. In other embodiments, both communications interface 407 andBMS interface 409 are Ethernet interfaces or are the same Ethernetinterface.

Still referring to FIG. 4, BMS controller 366 is shown to include aprocessing circuit 404 including a processor 406 and memory 408.Processing circuit 404 can be communicably connected to BMS interface409 and/or communications interface 407 such that processing circuit 404and the various components thereof can send and receive data viainterfaces 407, 409. Processor 406 can be implemented as a generalpurpose processor, an application specific integrated circuit (ASIC),one or more field programmable gate arrays (FPGAs), a group ofprocessing components, or other suitable electronic processingcomponents.

Memory 408 (e.g., memory, memory unit, storage device, etc.) can includeone or more devices (e.g., RAM, ROM, Flash memory, hard disk storage,etc.) for storing data and/or computer code for completing orfacilitating the various processes, layers and modules described in thepresent application. Memory 408 can be or include volatile memory ornon-volatile memory. Memory 408 can include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present application. According to anexemplary embodiment, memory 408 is communicably connected to processor406 via processing circuit 404 and includes computer code for executing(e.g., by processing circuit 404 and/or processor 406) one or moreprocesses described herein.

In some embodiments, BMS controller 366 is implemented within a singlecomputer (e.g., one server, one housing, etc.). In various otherembodiments BMS controller 366 can be distributed across multipleservers or computers (e.g., that can exist in distributed locations).Further, while FIG. 4 shows applications 422 and 426 as existing outsideof BMS controller 366, in some embodiments, applications 422 and 426 canbe hosted within BMS controller 366 (e.g., within memory 408).

Still referring to FIG. 4, memory 408 is shown to include an enterpriseintegration layer 410, an automated measurement and validation (AM&V)layer 412, a demand response (DR) layer 414, a fault detection anddiagnostics (FDD) layer 416, an integrated control layer 418, and abuilding subsystem integration later 420. Layers 410-420 can beconfigured to receive inputs from building subsystems 428 and other datasources, determine optimal control actions for building subsystems 428based on the inputs, generate control signals based on the optimalcontrol actions, and provide the generated control signals to buildingsubsystems 428. The following paragraphs describe some of the generalfunctions performed by each of layers 410-420 in BMS 400.

Enterprise integration layer 410 can be configured to serve clients orlocal applications with information and services to support a variety ofenterprise-level applications. For example, enterprise controlapplications 426 can be configured to provide subsystem-spanning controlto a graphical user interface (GUI) or to any number of enterprise-levelbusiness applications (e.g., accounting systems, user identificationsystems, etc.). Enterprise control applications 426 can also oralternatively be configured to provide configuration GUIs forconfiguring BMS controller 366. In yet other embodiments, enterprisecontrol applications 426 can work with layers 410-420 to optimizebuilding performance (e.g., efficiency, energy use, comfort, or safety)based on inputs received at interface 407 and/or BMS interface 409.

Building subsystem integration layer 420 can be configured to managecommunications between BMS controller 366 and building subsystems 428.For example, building subsystem integration layer 420 can receive sensordata and input signals from building subsystems 428 and provide outputdata and control signals to building subsystems 428. Building subsystemintegration layer 420 can also be configured to manage communicationsbetween building subsystems 428. Building subsystem integration layer420 translate communications (e.g., sensor data, input signals, outputsignals, etc.) across a plurality of multi-vendor/multi-protocolsystems.

Demand response layer 414 can be configured to optimize resource usage(e.g., electricity use, natural gas use, water use, etc.) and/or themonetary cost of such resource usage in response to satisfy the demandof building 10. The optimization can be based on time-of-use prices,curtailment signals, energy availability, or other data received fromutility providers, distributed energy generation systems 424, fromenergy storage 427 (e.g., hot TES 242, cold TES 244, etc.), or fromother sources. Demand response layer 414 can receive inputs from otherlayers of BMS controller 366 (e.g., building subsystem integration layer420, integrated control layer 418, etc.). The inputs received from otherlayers can include environmental or sensor inputs such as temperature,carbon dioxide levels, relative humidity levels, air quality sensoroutputs, occupancy sensor outputs, room schedules, and the like. Theinputs can also include inputs such as electrical use (e.g., expressedin kWh), thermal load measurements, pricing information, projectedpricing, smoothed pricing, curtailment signals from utilities, and thelike.

According to an exemplary embodiment, demand response layer 414 includescontrol logic for responding to the data and signals it receives. Theseresponses can include communicating with the control algorithms inintegrated control layer 418, changing control strategies, changingsetpoints, or activating/deactivating building equipment or subsystemsin a controlled manner. Demand response layer 414 can also includecontrol logic configured to determine when to utilize stored energy. Forexample, demand response layer 414 can determine to begin using energyfrom energy storage 427 just prior to the beginning of a peak use hour.

In some embodiments, demand response layer 414 includes a control moduleconfigured to actively initiate control actions (e.g., automaticallychanging setpoints) which minimize energy costs based on one or moreinputs representative of or based on demand (e.g., price, a curtailmentsignal, a demand level, etc.). In some embodiments, demand responselayer 414 uses equipment models to determine an optimal set of controlactions. The equipment models can include, for example, thermodynamicmodels describing the inputs, outputs, and/or functions performed byvarious sets of building equipment. Equipment models can representcollections of building equipment (e.g., subplants, chiller arrays,etc.) or individual devices (e.g., individual chillers, heaters, pumps,etc.).

Demand response layer 414 can further include or draw upon one or moredemand response policy definitions (e.g., databases, XML files, etc.).The policy definitions can be edited or adjusted by a user (e.g., via agraphical user interface) so that the control actions initiated inresponse to demand inputs can be tailored for the user's application,desired comfort level, particular building equipment, or based on otherconcerns. For example, the demand response policy definitions canspecify which equipment can be turned on or off in response toparticular demand inputs, how long a system or piece of equipment shouldbe turned off, what setpoints can be changed, what the allowable setpoint adjustment range is, how long to hold a high demand setpointbefore returning to a normally scheduled setpoint, how close to approachcapacity limits, which equipment modes to utilize, the energy transferrates (e.g., the maximum rate, an alarm rate, other rate boundaryinformation, etc.) into and out of energy storage devices (e.g., thermalstorage tanks, battery banks, etc.), and when to dispatch on-sitegeneration of energy (e.g., via fuel cells, a motor generator set,etc.).

Integrated control layer 418 can be configured to use the data input oroutput of building subsystem integration layer 420 and/or demandresponse later 414 to make control decisions. Due to the subsystemintegration provided by building subsystem integration layer 420,integrated control layer 418 can integrate control activities of thesubsystems 428 such that the subsystems 428 behave as a singleintegrated supersystem. In an exemplary embodiment, integrated controllayer 418 includes control logic that uses inputs and outputs from aplurality of building subsystems to provide greater comfort and energysavings relative to the comfort and energy savings that separatesubsystems could provide alone. For example, integrated control layer418 can be configured to use an input from a first subsystem to make anenergy-saving control decision for a second subsystem. Results of thesedecisions can be communicated back to building subsystem integrationlayer 420.

Integrated control layer 418 is shown to be logically below demandresponse layer 414. Integrated control layer 418 can be configured toenhance the effectiveness of demand response layer 414 by enablingbuilding subsystems 428 and their respective control loops to becontrolled in coordination with demand response layer 414. Thisconfiguration may advantageously reduce disruptive demand responsebehavior relative to conventional systems. For example, integratedcontrol layer 418 can be configured to assure that a demandresponse-driven upward adjustment to the setpoint for chilled watertemperature (or another component that directly or indirectly affectstemperature) does not result in an increase in fan energy (or otherenergy used to cool a space) that would result in greater total buildingenergy use than was saved at the chiller.

Integrated control layer 418 can be configured to provide feedback todemand response layer 414 so that demand response layer 414 checks thatconstraints (e.g., temperature, lighting levels, etc.) are properlymaintained even while demanded load shedding is in progress. Theconstraints can also include setpoint or sensed boundaries relating tosafety, equipment operating limits and performance, comfort, fire codes,electrical codes, energy codes, and the like. Integrated control layer418 is also logically below fault detection and diagnostics layer 416and automated measurement and validation layer 412. Integrated controllayer 418 can be configured to provide calculated inputs (e.g.,aggregations) to these higher levels based on outputs from more than onebuilding subsystem.

Automated measurement and validation (AM&V) layer 412 can be configuredto verify that control strategies commanded by integrated control layer418 or demand response layer 414 are working properly (e.g., using dataaggregated by AM&V layer 412, integrated control layer 418, buildingsubsystem integration layer 420, FDD layer 416, or otherwise). Thecalculations made by AM&V layer 412 can be based on building systemenergy models and/or equipment models for individual BMS devices orsubsystems. For example, AM&V layer 412 can compare a model-predictedoutput with an actual output from building subsystems 428 to determinean accuracy of the model.

Fault detection and diagnostics (FDD) layer 416 can be configured toprovide on-going fault detection for building subsystems 428, buildingsubsystem devices (i.e., building equipment), and control algorithmsused by demand response layer 414 and integrated control layer 418. FDDlayer 416 can receive data inputs from integrated control layer 418,directly from one or more building subsystems or devices, or fromanother data source. FDD layer 416 can automatically diagnose andrespond to detected faults. The responses to detected or diagnosedfaults can include providing an alert message to a user, a maintenancescheduling system, or a control algorithm configured to attempt torepair the fault or to work-around the fault.

FDD layer 416 can be configured to output a specific identification ofthe faulty component or cause of the fault (e.g., loose damper linkage)using detailed subsystem inputs available at building subsystemintegration layer 420. In other exemplary embodiments, FDD layer 416 isconfigured to provide “fault” events to integrated control layer 418which executes control strategies and policies in response to thereceived fault events. According to an exemplary embodiment, FDD layer416 (or a policy executed by an integrated control engine or businessrules engine) can shut-down systems or direct control activities aroundfaulty devices or systems to reduce energy waste, extend equipment life,or assure proper control response.

FDD layer 416 can be configured to store or access a variety ofdifferent system data stores (or data points for live data). FDD layer416 can use some content of the data stores to identify faults at theequipment level (e.g., specific chiller, specific AHU, specific terminalunit, etc.) and other content to identify faults at component orsubsystem levels. For example, building subsystems 428 can generatetemporal (i.e., time-series) data indicating the performance of BMS 400and the various components thereof. The data generated by buildingsubsystems 428 can include measured or calculated values that exhibitstatistical characteristics and provide information about how thecorresponding system or process (e.g., a temperature control process, aflow control process, etc.) is performing in terms of error from itssetpoint. These processes can be examined by FDD layer 416 to exposewhen the system begins to degrade in performance and alert a user torepair the fault before it becomes more severe.

Building Management System with Data Platform Services

Referring now to FIG. 5, a block diagram of another building managementsystem (BMS) 500 is shown, according to some embodiments. BMS 500 can beconfigured to collect data samples from building subsystems 428 andgenerate raw timeseries data from the data samples. BMS 500 can processand transform the raw timeseries data using data platform services 520to generate derived timeseries data. Throughout this disclosure, theterm “derived timeseries data” is used to describe the result or outputof a transformation or other timeseries processing operation performedby data platform services 520 (e.g., data aggregation, data cleansing,virtual point calculation, etc.). The derived timeseries data can beprovided to various applications 530 and/or stored in local storage 514or hosted storage 516 (e.g., as materialized views of the raw timeseriesdata). In some embodiments, BMS 500 separates data collection; datastorage, retrieval, and analysis; and data visualization into threedifferent layers. This allows BMS 500 to support a variety ofapplications 530 that use the derived timeseries data and allows newapplications 530 to reuse the existing infrastructure provided by dataplatform services 520.

Before discussing BMS 500 in greater detail, it should be noted that thecomponents of BMS 500 can be integrated within a single device (e.g., asupervisory controller, a BMS controller, etc.) or distributed acrossmultiple separate systems or devices. For example, the components of BMS500 can be implemented as part of a METASYS® brand building automationsystem, as sold by Johnson Controls Inc. In other embodiments, some orall of the components of BMS 500 can be implemented as part of acloud-based computing system configured to receive and process data fromone or more building management systems. In other embodiments, some orall of the components of BMS 500 can be components of a subsystem levelcontroller (e.g., a HVAC controller), a subplant controller, a devicecontroller (e.g., AHU controller 330, a chiller controller, etc.), afield controller, a computer workstation, a client device, or any othersystem or device that receives and processes data from buildingequipment.

BMS 500 can include many of the same components as BMS 400, as describedwith reference to FIG. 4. For example, BMS 500 is shown to include a BMSinterface 502 and a communications interface 504. Interfaces 502-504 caninclude wired or wireless communications interfaces (e.g., jacks,antennas, transmitters, receivers, transceivers, wire terminals, etc.)for conducting data communications with building subsystems 428 or otherexternal systems or devices. Communications conducted via interfaces502-504 can be direct (e.g., local wired or wireless communications) orvia a communications network 446 (e.g., a WAN, the Internet, a cellularnetwork, etc.).

Communications interface 504 can facilitate communications between BMS500 and external applications (e.g., remote systems and applications444) for allowing user control, monitoring, and adjustment to BMS 500.Communications interface 504 can also facilitate communications betweenBMS 500 and client devices 448. BMS interface 502 can facilitatecommunications between BMS 500 and building subsystems 428. BMS 500 canbe configured to communicate with building subsystems 428 using any of avariety of building automation systems protocols (e.g., BACnet, Modbus,ADX, etc.). In some embodiments, BMS 500 receives data samples frombuilding subsystems 428 and provides control signals to buildingsubsystems 428 via BMS interface 502.

Building subsystems 428 can include building electrical subsystem 434,information communication technology (ICT) subsystem 436, securitysubsystem 438, HVAC subsystem 440, lighting subsystem 442,lift/escalators subsystem 432, and/or fire safety subsystem 430, asdescribed with reference to FIG. 4. In various embodiments, buildingsubsystems 428 can include fewer, additional, or alternative subsystems.For example, building subsystems 428 can also or alternatively include arefrigeration subsystem, an advertising or signage subsystem, a cookingsubsystem, a vending subsystem, a printer or copy service subsystem, orany other type of building subsystem that uses controllable equipmentand/or sensors to monitor or control building 10. In some embodiments,building subsystems 428 include waterside system 200 and/or airsidesystem 300, as described with reference to FIGS. 2-3. Each of buildingsubsystems 428 can include any number of devices, controllers, andconnections for completing its individual functions and controlactivities. Building subsystems 428 can include building equipment(e.g., sensors, air handling units, chillers, pumps, valves, etc.)configured to monitor and control a building condition such astemperature, humidity, airflow, etc.

Still referring to FIG. 5, BMS 500 is shown to include a processingcircuit 506 including a processor 508 and memory 510. Processor 508 canbe a general purpose or specific purpose processor, an applicationspecific integrated circuit (ASIC), one or more field programmable gatearrays (FPGAs), a group of processing components, or other suitableprocessing components. Processor 508 is configured to execute computercode or instructions stored in memory 510 or received from othercomputer readable media (e.g., CDROM, network storage, a remote server,etc.).

Memory 510 can include one or more devices (e.g., memory units, memorydevices, storage devices, etc.) for storing data and/or computer codefor completing and/or facilitating the various processes described inthe present disclosure. Memory 510 can include random access memory(RAM), read-only memory (ROM), hard drive storage, temporary storage,non-volatile memory, flash memory, optical memory, or any other suitablememory for storing software objects and/or computer instructions. Memory510 can include database components, object code components, scriptcomponents, or any other type of information structure for supportingthe various activities and information structures described in thepresent disclosure. Memory 510 can be communicably connected toprocessor 508 via processing circuit 506 and can include computer codefor executing (e.g., by processor 508) one or more processes describedherein. When processor 508 executes instructions stored in memory 510,processor 508 generally configures processing circuit 506 to completesuch activities.

Still referring to FIG. 5, BMS 500 is shown to include a data collector512. Data collector 512 is shown receiving data samples from buildingsubsystems 428 via BMS interface 502. In some embodiments, the datasamples include data values for various data points. The data values canbe measured or calculated values, depending on the type of data point.For example, a data point received from a temperature sensor can includea measured data value indicating a temperature measured by thetemperature sensor. A data point received from a chiller controller caninclude a calculated data value indicating a calculated efficiency ofthe chiller. Data collector 512 can receive data samples from multipledifferent devices within building subsystems 428.

The data samples can include one or more attributes that describe orcharacterize the corresponding data points. For example, the datasamples can include a name attribute defining a point name or ID (e.g.,“B1F4R2.T-Z”), a device attribute indicating a type of device from whichthe data samples is received (e.g., temperature sensor, humidity sensor,chiller, etc.), a unit attribute defining a unit of measure associatedwith the data value (e.g., ° F., ° C., kPA, etc.), and/or any otherattribute that describes the corresponding data point or providescontextual information regarding the data point. The types of attributesincluded in each data point can depend on the communications protocolused to send the data samples to BMS 500. For example, data samplesreceived via the ADX protocol or BACnet protocol can include a varietyof descriptive attributes along with the data value, whereas datasamples received via the Modbus protocol may include a lesser number ofattributes (e.g., only the data value without any correspondingattributes).

In some embodiments, each data sample is received with a timestampindicating a time at which the corresponding data value was measured orcalculated. In other embodiments, data collector 512 adds timestamps tothe data samples based on the times at which the data samples arereceived. Data collector 512 can generate raw timeseries data for eachof the data points for which data samples are received. Each timeseriescan include a series of data values for the same data point and atimestamp for each of the data values. For example, a timeseries for adata point provided by a temperature sensor can include a series oftemperature values measured by the temperature sensor and thecorresponding times at which the temperature values were measured. Anexample of a timeseries which can be generated by data collector 512 isas follows:

-   -   [<key, timestamp₁, value₁>, <key, timestamp₂, value₂>, <key,        timestamp₃, value₃>]        where key is an identifier of the source of the raw data samples        (e.g., timeseries ID, sensor ID, etc.), timestamp_(i) identifies        the time at which the ith sample was collected, and value_(i)        indicates the value of the ith sample.

Data collector 512 can add timestamps to the data samples or modifyexisting timestamps such that each data sample includes a localtimestamp. Each local timestamp indicates the local time at which thecorresponding data sample was measured or collected and can include anoffset relative to universal time. The local timestamp indicates thelocal time at the location the data point was measured at the time ofmeasurement. The offset indicates the difference between the local timeand a universal time (e.g., the time at the international date line).For example, a data sample collected in a time zone that is six hoursbehind universal time can include a local timestamp (e.g.,Timestamp=2016-03-18T14:10:02) and an offset indicating that the localtimestamp is six hours behind universal time (e.g., Offset=−6:00). Theoffset can be adjusted (e.g., +1:00 or −1:00) depending on whether thetime zone is in daylight savings time when the data sample is measuredor collected.

The combination of the local timestamp and the offset provides a uniquetimestamp across daylight saving time boundaries. This allows anapplication using the timeseries data to display the timeseries data inlocal time without first converting from universal time. The combinationof the local timestamp and the offset also provides enough informationto convert the local timestamp to universal time without needing to lookup a schedule of when daylight savings time occurs. For example, theoffset can be subtracted from the local timestamp to generate auniversal time value that corresponds to the local timestamp withoutreferencing an external database and without requiring any otherinformation.

In some embodiments, data collector 512 organizes the raw timeseriesdata. Data collector 512 can identify a system or device associated witheach of the data points. For example, data collector 512 can associate adata point with a temperature sensor, an air handler, a chiller, or anyother type of system or device. In various embodiments, data collectoruses the name of the data point, a range of values of the data point,statistical characteristics of the data point, or other attributes ofthe data point to identify a particular system or device associated withthe data point. Data collector 512 can then determine how that system ordevice relates to the other systems or devices in the building site. Forexample, data collector 512 can determine that the identified system ordevice is part of a larger system (e.g., a HVAC system) or serves aparticular space (e.g., a particular building, a room or zone of thebuilding, etc.). In some embodiments, data collector 512 uses or createsan entity graph when organizing the timeseries data. An example of suchan entity graph is described in greater detail with reference to FIG.10A.

Data collector 512 can provide the raw timeseries data to data platformservices 520 and/or store the raw timeseries data in local storage 514or hosted storage 516. As shown in FIG. 5, local storage 514 can be datastorage internal to BMS 500 (e.g., within memory 510) or other on-sitedata storage local to the building site at which the data samples arecollected. Hosted storage 516 can include a remote database, cloud-baseddata hosting, or other remote data storage. For example, hosted storage516 can include remote data storage located off-site relative to thebuilding site at which the data samples are collected. Local storage 514and hosted storage 516 can be configured to store the raw timeseriesdata obtained by data collector 512, the derived timeseries datagenerated by data platform services 520, and/or directed acyclic graphs(DAGs) used by data platform services 520 to process the timeseriesdata.

Still referring to FIG. 5, BMS 500 is shown to include data platformservices 520. Data platform services 520 can receive the raw timeseriesdata from data collector 512 and/or retrieve the raw timeseries datafrom local storage 514 or hosted storage 516. Data platform services 520can include a variety of services configured to analyze, process, andtransform the raw timeseries data. For example, data platform services520 are shown to include a security service 522, an analytics service524, an entity service 526, and a timeseries service 528. Securityservice 522 can assign security attributes to the raw timeseries data toensure that the timeseries data are only accessible to authorizedindividuals, systems, or applications. Entity service 524 can assignentity information to the timeseries data to associate data points witha particular system, device, or space. Timeseries service 528 andanalytics service 524 can apply various transformations, operations, orother functions to the raw timeseries data to generate derivedtimeseries data.

In some embodiments, timeseries service 528 aggregates predefinedintervals of the raw timeseries data (e.g., quarter-hourly intervals,hourly intervals, daily intervals, monthly intervals, etc.) to generatenew derived timeseries of the aggregated values. These derivedtimeseries can be referred to as “data rollups” since they are condensedversions of the raw timeseries data. The data rollups generated bytimeseries service 528 provide an efficient mechanism for applications530 to query the timeseries data. For example, applications 530 canconstruct visualizations of the timeseries data (e.g., charts, graphs,etc.) using the pre-aggregated data rollups instead of the rawtimeseries data. This allows applications 530 to simply retrieve andpresent the pre-aggregated data rollups without requiring applications530 to perform an aggregation in response to the query. Since the datarollups are pre-aggregated, applications 530 can present the datarollups quickly and efficiently without requiring additional processingat query time to generate aggregated timeseries values.

In some embodiments, timeseries service 528 calculates virtual pointsbased on the raw timeseries data and/or the derived timeseries data.Virtual points can be calculated by applying any of a variety ofmathematical operations (e.g., addition, subtraction, multiplication,division, etc.) or functions (e.g., average value, maximum value,minimum value, thermodynamic functions, linear functions, nonlinearfunctions, etc.) to the actual data points represented by the timeseriesdata. For example, timeseries service 528 can calculate a virtual datapoint (pointID₃) by adding two or more actual data points (pointID₁ andpointID₂) (e.g., pointID₃=pointID₁+pointID₂). As another example,timeseries service 528 can calculate an enthalpy data point (pointID₄)based on a measured temperature data point (pointID₅) and a measuredpressure data point (pointID₆) (e.g., pointID₄=enthalpy(pointID₅,pointID₆)). The virtual data points can be stored as derived timeseriesdata.

Applications 530 can access and use the virtual data points in the samemanner as the actual data points. Applications 530 do not need to knowwhether a data point is an actual data point or a virtual data pointsince both types of data points can be stored as derived timeseries dataand can be handled in the same manner by applications 530. In someembodiments, the derived timeseries are stored with attributesdesignating each data point as either a virtual data point or an actualdata point. Such attributes allow applications 530 to identify whether agiven timeseries represents a virtual data point or an actual datapoint, even though both types of data points can be handled in the samemanner by applications 530. These and other features of timeseriesservice 528 are described in greater detail with reference to FIG. 6.

In some embodiments, analytics service 524 analyzes the raw timeseriesdata and/or the derived timeseries data to detect faults. Analyticsservice 524 can apply a set of fault detection rules to the timeseriesdata to determine whether a fault is detected at each interval of thetimeseries. Fault detections can be stored as derived timeseries data.For example, analytics service 524 can generate a new fault detectiontimeseries with data values that indicate whether a fault was detectedat each interval of the timeseries. An example of such a fault detectiontimeseries is described in greater detail with reference to FIG. 9B. Thefault detection timeseries can be stored as derived timeseries dataalong with the raw timeseries data in local storage 514 or hostedstorage 516.

Still referring to FIG. 5, BMS 500 is shown to include severalapplications 530 including an energy management application 532,monitoring and reporting applications 534, and enterprise controlapplications 536. Although only a few applications 530 are shown, it iscontemplated that applications 530 can include any of a variety ofapplications configured to use the derived timeseries generated by dataplatform services 520. In some embodiments, applications 530 exist as aseparate layer of BMS 500 (i.e., separate from data platform services520 and data collector 512). This allows applications 530 to be isolatedfrom the details of how the derived timeseries are generated. In otherembodiments, applications 530 can exist as remote applications that runon remote systems or devices (e.g., remote systems and applications 444,client devices 448).

Applications 530 can use the derived timeseries data to perform avariety data visualization, monitoring, and/or control activities. Forexample, energy management application 532 and monitoring and reportingapplication 534 can use the derived timeseries data to generate userinterfaces (e.g., charts, graphs, etc.) that present the derivedtimeseries data to a user. In some embodiments, the user interfacespresent the raw timeseries data and the derived data rollups in a singlechart or graph. For example, a dropdown selector can be provided toallow a user to select the raw timeseries data or any of the datarollups for a given data point. Several examples of user interfaces thatcan be generated based on the derived timeseries data are described inU.S. patent application Ser. No. 15/182,579 filed Jun. 14, 2016, andU.S. Provisional Patent Application No. 62/446,284 filed Jan. 13, 2017.The entire disclosures of both these patent applications areincorporated by reference herein.

Enterprise control application 536 can use the derived timeseries datato perform various control activities. For example, enterprise controlapplication 536 can use the derived timeseries data as input to acontrol algorithm (e.g., a state-based algorithm, an extremum seekingcontrol (ESC) algorithm, a proportional-integral (PI) control algorithm,a proportional-integral-derivative (PID) control algorithm, a modelpredictive control (MPC) algorithm, a feedback control algorithm, etc.)to generate control signals for building subsystems 428. In someembodiments, building subsystems 428 use the control signals to operatebuilding equipment. Operating the building equipment can affect themeasured or calculated values of the data samples provided to BMS 500.Accordingly, enterprise control application 536 can use the derivedtimeseries data as feedback to control the systems and devices ofbuilding subsystems 428.

Timeseries Data Platform Service

Referring now to FIG. 6, a block diagram illustrating timeseries service528 in greater detail is shown, according to some embodiments.Timeseries service 528 is shown to include a timeseries web service 602,an events service 603, a timeseries processing engine 604, and atimeseries storage interface 616. Timeseries web service 602 can beconfigured to interact with web-based applications to send and/orreceive timeseries data. In some embodiments, timeseries web service 602provides timeseries data to web-based applications. For example, if oneor more of applications 530 are web-based applications, timeseries webservice 602 can provide derived timeseries data and raw timeseries datato the web-based applications. In some embodiments, timeseries webservice 602 receives raw timeseries data from a web-based datacollector. For example, if data collector 512 is a web-basedapplication, timeseries web service 602 can receive data samples or rawtimeseries data from data collector 512.

Timeseries storage interface 616 can be configured to store and readsamples of various timeseries (e.g., raw timeseries data and derivedtimeseries data) and eventseries (described in greater detail below).Timeseries storage interface 616 can interact with local storage 514and/or hosted storage 516. For example, timeseries storage interface 616can retrieve timeseries data from a local timeseries database 628 withinlocal storage 514 or from a hosted timeseries database 636 within hostedstorage 516. In some embodiments, timeseries storage interface 616 readssamples from a specified start time or start position in the timeseriesto a specified stop time or a stop position in the timeseries.Similarly, timeseries storage interface 616 can retrieve eventseriesdata from a local eventseries database 629 within local storage 514 orfrom a hosted eventseries database 637 within hosted storage 516.Timeseries storage interface 616 can also store timeseries data in localtimeseries database 628 or hosted timeseries database 636 and can storeeventseries data in local eventseries database 629 or hosted eventseriesdatabase 637. Advantageously, timeseries storage interface 616 providesa consistent interface which enables logical data independence.

In some embodiments, timeseries storage interface 616 stores timeseriesas lists of data samples, organized by time. For example, timeseriesstorage interface 616 can store timeseries in the following format:

-   -   [<key, timestamp₁, value₁>, <key, timestamp₂, value₂>, <key,        timestamp₃, value₃>]        where key is an identifier of the source of the data samples        (e.g., timeseries ID, sensor ID, etc.), timestamp_(i) identifies        a time associated with the ith sample, and value_(i) indicates        the value of the ith sample.

In some embodiments, timeseries storage interface 616 stores eventseriesas lists of events having a start time, an end time, and a state. Forexample, timeseries storage interface 616 can store eventseries in thefollowing format:

-   -   [<eventID₁, start_timestamp₁, end_timestamp₁, state₁>, . . . ,        <eventID_(N), start_timestamp_(N), end_timestamp_(N),        state_(N)>]        where eventID_(i) is an identifier of the ith event,        start_timestamp_(i) is the time at which the ith event started,        end_timestamp_(i) is the time at which the ith event ended,        state_(i) describes a state or condition associated with the ith        event (e.g., cold, hot, warm, etc.), and N is the total number        of events in the eventseries.

In some embodiments, timeseries storage interface 616 stores timeseriesand eventseries in a tabular format. Timeseries storage interface 616can store timeseries and eventseries in various tables having a columnfor each attribute of the timeseries/eventseries samples (e.g., key,timestamp, value). The timeseries tables can be stored in localtimeseries database 628 and/or hosted timeseries database 636, whereasthe eventseries tables can be stored in local eventseries database 629and/or hosted eventseries database 637. In some embodiments, timeseriesstorage interface 616 caches older data to local storage 514 or hostedstorage 516 but stores newer data in RAM. This may improve readperformance when the newer data are requested for processing.

In some embodiments, timeseries storage interface 616 omits one or moreof the attributes when storing the timeseries samples. For example,timeseries storage interface 616 may not need to repeatedly store thekey or timeseries ID for each sample in the timeseries. In someembodiments, timeseries storage interface 616 omits timestamps from oneor more of the samples. If samples of a particular timeseries havetimestamps at regular intervals (e.g., one sample each minute),timeseries storage interface 616 can organize the samples by timestampsand store the values of the samples in a row. The timestamp of the firstsample can be stored along with the interval between the timestamps.Timeseries storage interface 616 can determine the timestamp of anysample in the row based on the timestamp of the first sample and theposition of the sample in the row.

In some embodiments, timeseries storage interface 616 stores one or moresamples with an attribute indicating a change in value relative to theprevious sample value. The change in value can replace the actual valueof the sample when the sample is stored in local timeseries database 628or hosted timeseries database 636. This allows timeseries storageinterface 616 to use fewer bits when storing samples and theircorresponding values. Timeseries storage interface 616 can determine thevalue of any sample based on the value of the first sample and thechange in value of each successive sample.

In some embodiments, timeseries storage interface 616 creates containersor data objects in which samples of timeseries data can be stored. Thecontainers can be JSON objects or other types of containers configuredto store one or more timeseries samples and/or eventseries samples.Timeseries storage interface 616 can be configured to add samples to thecontainers and read samples from the containers. For example, timeseriesstorage interface 616 can receive a set of samples from data collector512, timeseries web service 602, events service 603, and/or timeseriesprocessing engine 604. Timeseries storage interface 616 can add the setof samples to a container and send the container to local storage 514 orhosted storage 516.

Timeseries storage interface 616 can use containers when reading samplesfrom local storage 514 or hosted storage 516. For example, timeseriesstorage interface 616 can retrieve a set of samples from local storage514 or hosted storage 516 and add the samples to a container. In someembodiments, the set of samples include all samples within a specifiedtime period (e.g., samples with timestamps in the specified time period)or eventseries samples having a specified state. Timeseries storageinterface 616 can provide the container of samples to timeseries webservice 602, events service 603, timeseries processing engine 604,applications 530, and/or other components configured to use thetimeseries/eventseries samples.

Still referring to FIG. 6, timeseries processing engine 604 is shown toinclude several timeseries operators 606. Timeseries operators 606 canbe configured to apply various operations, transformations, or functionsto one or more input timeseries to generate output timeseries and/oreventseries. The input timeseries can include raw timeseries data and/orderived timeseries data. Timeseries operators 606 can be configured tocalculate aggregate values, averages, or apply other mathematicaloperations to the input timeseries. In some embodiments, timeseriesoperators 606 generate virtual point timeseries by combining two or moreinput timeseries (e.g., adding the timeseries together), creatingmultiple output timeseries from a single input timeseries, or applyingmathematical operations to the input timeseries. In some embodiments,timeseries operators 606 perform data cleansing operations ordeduplication operations on an input timeseries. In some embodiments,timeseries operators 606 use the input timeseries to generateeventseries based on the values of the timeseries samples (described ingreater detail below). The output timeseries can be stored as derivedtimeseries data in local storage 514 and/or hosted storage 516.Similarly, the eventseries can be stored as eventseries data in localstorage 514 and/or hosted storage 516.

In some embodiments, timeseries operators 606 do not change or replacethe raw timeseries data, but rather generate various “views” of the rawtimeseries data. The views can be queried in the same manner as the rawtimeseries data. For example, samples can be read from the rawtimeseries data, transformed to create the view, and then provided as anoutput. Because the transformations used to create the views can becomputationally expensive, the views can be stored as “materializedviews” in local timeseries database 628 or hosted timeseries database636. These materialized views are referred to as derived timeseries datathroughout the present disclosure.

Timeseries operators 606 can be configured to run at query time (e.g.,when a request for derived timeseries data is received) or prior toquery time (e.g., when new raw data samples are received, in response toa defined event or trigger, etc.). This flexibility allows timeseriesoperators 606 to perform some or all of their operations ahead of timeand/or in response to a request for specific derived data timeseries.For example, timeseries operators 606 can be configured to pre-processone or more timeseries that are read frequently to ensure that thetimeseries are updated whenever new data samples are received. However,timeseries operators 606 can be configured to wait until query time toprocess one or more timeseries that are read infrequently to avoidperforming unnecessary processing operations.

In some embodiments, timeseries operators 606 are triggered in aparticular sequence defined by a directed acyclic graph (DAG). The DAGmay define a workflow or sequence of operations or transformations toapply to one or more input timeseries. For example, the DAG for a rawdata timeseries may include a data cleansing operation, an aggregationoperation, and a summation operation (e.g., adding two raw datatimeseries to create a virtual point timeseries). The DAGs can be storedin a local DAG database 630 within local storage 514, in a hosted DAGdatabase 638 within hosted storage 516, or internally within timeseriesprocessing engine 604. DAGs can be retrieved by workflow manager 622 andused to determine how and when to process incoming data samples.Exemplary systems and methods for creating and using DAGs are describedin greater detail below.

Timeseries operators 606 can perform aggregations for dashboards,cleansing operations, logical operations for rules and fault detection,machine learning predictions or classifications, call out to externalservices, or any of a variety of other operations which can be appliedto timeseries data. The operations performed by timeseries operators 606are not limited to sensor data. Timeseries operators 606 can alsooperate on event data or function as a billing engine for a consumptionor tariff-based billing system.

Sample Aggregation

Still referring to FIG. 6, timeseries operators 606 are shown to includea sample aggregator 608. Sample aggregator 608 can be configured togenerate derived data rollups from the raw timeseries data. For eachdata point, sample aggregator 608 can aggregate a set of data valueshaving timestamps within a predetermined time interval (e.g., aquarter-hour, an hour, a day, etc.) to generate an aggregate data valuefor the predetermined time interval. For example, the raw timeseriesdata for a particular data point may have a relatively short interval(e.g., one minute) between consecutive samples of the data point. Sampleaggregator 608 can generate a data rollup from the raw timeseries databy aggregating all of the samples of the data point having timestampswithin a relatively longer interval (e.g., a quarter-hour) into a singleaggregated value that represents the longer interval.

For some types of timeseries, sample aggregator 608 performs theaggregation by averaging all of the samples of the data point havingtimestamps within the longer interval. Aggregation by averaging can beused to calculate aggregate values for timeseries of non-cumulativevariables such as measured value. For other types of timeseries, sampleaggregator 608 performs the aggregation by summing all of the samples ofthe data point having timestamps within the longer interval. Aggregationby summation can be used to calculate aggregate values for timeseries ofcumulative variables such as the number of faults detected since theprevious sample.

Referring now to FIGS. 7A-7B, a block diagram 700 and a data table 750illustrating an aggregation technique which can be used by sampleaggregator 608 is shown, according to some embodiments. In FIG. 7A, adata point 702 is shown. Data point 702 is an example of a measured datapoint for which timeseries values can be obtained. For example, datapoint 702 is shown as an outdoor air temperature point and has valueswhich can be measured by a temperature sensor. Although a specific typeof data point 702 is shown in FIG. 7A, it should be understood that datapoint 702 can be any type of measured or calculated data point.Timeseries values of data point 702 can be collected by data collector512 and assembled into a raw data timeseries 704.

As shown in FIG. 7B, the raw data timeseries 704 includes a timeseriesof data samples, each of which is shown as a separate row in data table750. Each sample of raw data timeseries 704 is shown to include atimestamp and a data value. The timestamps of raw data timeseries 704are ten minutes and one second apart, indicating that the samplinginterval of raw data timeseries 704 is ten minutes and one second. Forexample, the timestamp of the first data sample is shown as2015-12-31T23: 10: 00 indicating that the first data sample of raw datatimeseries 704 was collected at 11:10:00 PM on Dec. 31, 2015. Thetimestamp of the second data sample is shown as 2015-12-31T23: 20: 01indicating that the second data sample of raw data timeseries 704 wascollected at 11:20:01 PM on Dec. 31, 2015. In some embodiments, thetimestamps of raw data timeseries 704 are stored along with an offsetrelative to universal time, as previously described. The values of rawdata timeseries 704 start at a value of 10 and increase by 10 with eachsample. For example, the value of the second sample of raw datatimeseries 704 is 20, the value of the third sample of raw datatimeseries 704 is 30, etc.

In FIG. 7A, several data rollup timeseries 706-714 are shown. Datarollup timeseries 706-714 can be generated by sample aggregator 608 andstored as derived timeseries data. The data rollup timeseries 706-714include an average quarter-hour timeseries 706, an average hourlytimeseries 708, an average daily timeseries 710, an average monthlytimeseries 712, and an average yearly timeseries 714. Each of the datarollup timeseries 706-714 is dependent upon a parent timeseries. In someembodiments, the parent timeseries for each of the data rolluptimeseries 706-714 is the timeseries with the next shortest durationbetween consecutive timeseries values. For example, the parenttimeseries for average quarter-hour timeseries 706 is raw datatimeseries 704. Similarly, the parent timeseries for average hourlytimeseries 708 is average quarter-hour timeseries 706; the parenttimeseries for average daily timeseries 710 is average hourly timeseries708; the parent timeseries for average monthly timeseries 712 is averagedaily timeseries 710; and the parent timeseries for average yearlytimeseries 714 is average monthly timeseries 712.

Sample aggregator 608 can generate each of the data rollup timeseries706-714 from the timeseries values of the corresponding parenttimeseries. For example, sample aggregator 608 can generate averagequarter-hour timeseries 706 by aggregating all of the samples of datapoint 702 in raw data timeseries 704 that have timestamps within eachquarter-hour. Similarly, sample aggregator 608 can generate averagehourly timeseries 708 by aggregating all of the timeseries values ofaverage quarter-hour timeseries 706 that have timestamps within eachhour. Sample aggregator 608 can generate average daily timeseries 710 byaggregating all of the time series values of average hourly timeseries708 that have timestamps within each day. Sample aggregator 608 cangenerate average monthly timeseries 712 by aggregating all of the timeseries values of average daily timeseries 710 that have timestampswithin each month. Sample aggregator 608 can generate average yearlytimeseries 714 by aggregating all of the time series values of averagemonthly timeseries 712 that have timestamps within each year.

In some embodiments, the timestamps for each sample in the data rolluptimeseries 706-714 are the beginnings of the aggregation interval usedto calculate the value of the sample. For example, the first data sampleof average quarter-hour timeseries 706 is shown to include the timestamp2015-12-31T23: 00: 00. This timestamp indicates that the first datasample of average quarter-hour timeseries 706 corresponds to anaggregation interval that begins at 11:00:00 PM on Dec. 31, 2015. Sinceonly one data sample of raw data timeseries 704 occurs during thisinterval, the value of the first data sample of average quarter-hourtimeseries 706 is the average of a single data value (i.e.,average(10)=10). The same is true for the second data sample of averagequarter-hour timeseries 706 (i.e., average (20)=20).

The third data sample of average quarter-hour timeseries 706 is shown toinclude the timestamp 2015-12-31T23: 30: 00. This timestamp indicatesthat the third data sample of average quarter-hour timeseries 706corresponds to an aggregation interval that begins at 11:30:00 PM onDec. 31, 2015. Since each aggregation interval of average quarter-hourtimeseries 706 is a quarter-hour in duration, the end of the aggregationinterval is 11:45:00 PM on Dec. 31, 2015. This aggregation intervalincludes two data samples of raw data timeseries 704 (i.e., the thirdraw data sample having a value of 30 and the fourth raw data samplehaving a value of 40). Sample aggregator 608 can calculate the value ofthe third sample of average quarter-hour timeseries 706 by averaging thevalues of the third raw data sample and the fourth raw data sample(i.e., average(30, 40)=35). Accordingly, the third sample of averagequarter-hour timeseries 706 has a value of 35. Sample aggregator 608 cancalculate the remaining values of average quarter-hour timeseries 706 ina similar manner.

Still referring to FIG. 7B, the first data sample of average hourlytimeseries 708 is shown to include the timestamp 2015-12-31T23: 00: 00.This timestamp indicates that the first data sample of average hourlytimeseries 708 corresponds to an aggregation interval that begins at11:00:00 PM on Dec. 31, 2015. Since each aggregation interval of averagehourly timeseries 708 is an hour in duration, the end of the aggregationinterval is 12:00:00 AM on Jan. 1, 2016. This aggregation intervalincludes the first four samples of average quarter-hour timeseries 706.Sample aggregator 608 can calculate the value of the first sample ofaverage hourly timeseries 708 by averaging the values of the first fourvalues of average quarter-hour timeseries 706 (i.e., average(10, 20, 35,50)=28.8). Accordingly, the first sample of average hourly timeseries708 has a value of 28.8. Sample aggregator 608 can calculate theremaining values of average hourly timeseries 708 in a similar manner.

The first data sample of average daily timeseries 710 is shown toinclude the timestamp 2015-12-31T00: 00: 00. This timestamp indicatesthat the first data sample of average daily timeseries 710 correspondsto an aggregation interval that begins at 12:00:00 AM on Dec. 31, 2015.Since each aggregation interval of the average daily timeseries 710 is aday in duration, the end of the aggregation interval is 12:00:00 AM onJan. 1, 2016. Only one data sample of average hourly timeseries 708occurs during this interval. Accordingly, the value of the first datasample of average daily timeseries 710 is the average of a single datavalue (i.e., average (28.8)=28.8). The same is true for the second datasample of average daily timeseries 710 (i.e., average(87.5)=87.5).

In some embodiments, sample aggregator 608 stores each of the datarollup timeseries 706-714 in a single data table (e.g., data table 750)along with raw data timeseries 704. This allows applications 530 toretrieve all of the timeseries 704-714 quickly and efficiently byaccessing a single data table. In other embodiments, sample aggregator608 can store the various timeseries 704-714 in separate data tableswhich can be stored in the same data storage device (e.g., the samedatabase) or distributed across multiple data storage devices. In someembodiments, sample aggregator 608 stores data timeseries 704-714 in aformat other than a data table. For example, sample aggregator 608 canstore timeseries 704-714 as vectors, as a matrix, as a list, or usingany of a variety of other data storage formats.

In some embodiments, sample aggregator 608 automatically updates thedata rollup timeseries 706-714 each time a new raw data sample isreceived. Updating the data rollup timeseries 706-714 can includerecalculating the aggregated values based on the value and timestamp ofthe new raw data sample. When a new raw data sample is received, sampleaggregator 608 can determine whether the timestamp of the new raw datasample is within any of the aggregation intervals for the samples of thedata rollup timeseries 706-714. For example, if a new raw data sample isreceived with a timestamp of 2016-01-01T00: 52: 00, sample aggregator608 can determine that the new raw data sample occurs within theaggregation interval beginning at timestamp 2016-01-01T00: 45: 00 foraverage quarter-hour timeseries 706. Sample aggregator 608 can use thevalue of the new raw data point (e.g., value=120) to update theaggregated value of the final data sample of average quarter-hourtimeseries 706 (i.e., average(110, 120)=115).

If the new raw data sample has a timestamp that does not occur withinany of the previous aggregation intervals, sample aggregator 608 cancreate a new data sample in average quarter-hour timeseries 706. The newdata sample in average quarter-hour timeseries 706 can have a new datatimestamp defining the beginning of an aggregation interval thatincludes the timestamp of the new raw data sample. For example, if thenew raw data sample has a timestamp of 2016-01-01T01: 00: 11, sampleaggregator 608 can determine that the new raw data sample does not occurwithin any of the aggregation intervals previously established foraverage quarter-hour timeseries 706. Sample aggregator 608 can generatea new data sample in average quarter-hour timeseries 706 with thetimestamp 2016-01-01T01: 00: 00 and can calculate the value of the newdata sample in average quarter-hour timeseries 706 based on the value ofthe new raw data sample, as previously described.

Sample aggregator 608 can update the values of the remaining data rolluptimeseries 708-714 in a similar manner. For example, sample aggregator608 determine whether the timestamp of the updated data sample inaverage quarter-hour timeseries is within any of the aggregationintervals for the samples of average hourly timeseries 708. Sampleaggregator 608 can determine that the timestamp 2016-01-01T00: 45: 00occurs within the aggregation interval beginning at timestamp2016-01-01T00: 00: 00 for average hourly timeseries 708. Sampleaggregator 608 can use the updated value of the final data sample ofaverage quarter-hour timeseries 706 (e.g., value=115) to update thevalue of the second sample of average hourly timeseries 708 (i.e.,average (65, 80, 95, 115)=88.75). Sample aggregator 608 can use theupdated value of the final data sample of average hourly timeseries 708to update the final sample of average daily timeseries 710 using thesame technique.

In some embodiments, sample aggregator 608 updates the aggregated datavalues of data rollup timeseries 706-714 each time a new raw data sampleis received. Updating each time a new raw data sample is receivedensures that the data rollup timeseries 706-714 always reflect the mostrecent data samples. In other embodiments, sample aggregator 608 updatesthe aggregated data values of data rollup timeseries 706-714periodically at predetermined update intervals (e.g., hourly, daily,etc.) using a batch update technique. Updating periodically can be moreefficient and require less data processing than updating each time a newdata sample is received, but can result in aggregated data values thatare not always updated to reflect the most recent data samples.

In some embodiments, sample aggregator 608 is configured to cleanse rawdata timeseries 704. Cleansing raw data timeseries 704 can includediscarding exceptionally high or low data. For example, sampleaggregator 608 can identify a minimum expected data value and a maximumexpected data value for raw data timeseries 704. Sample aggregator 608can discard data values outside this range as bad data. In someembodiments, the minimum and maximum expected values are based onattributes of the data point represented by the timeseries. For example,data point 702 represents a measured outdoor air temperature andtherefore has an expected value within a range of reasonable outdoor airtemperature values for a given geographic location (e.g., between −20°F. and 110° F.). Sample aggregator 608 can discard a data value of 330for data point 702 since a temperature value of 330° F. is notreasonable for a measured outdoor air temperature.

In some embodiments, sample aggregator 608 identifies a maximum rate atwhich a data point can change between consecutive data samples. Themaximum rate of change can be based on physical principles (e.g., heattransfer principles), weather patterns, or other parameters that limitthe maximum rate of change of a particular data point. For example, datapoint 702 represents a measured outdoor air temperature and thereforecan be constrained to have a rate of change less than a maximumreasonable rate of change for outdoor temperature (e.g., five degreesper minute). If two consecutive data samples of the raw data timeseries704 have values that would require the outdoor air temperature to changeat a rate in excess of the maximum expected rate of change, sampleaggregator 608 can discard one or both of the data samples as bad data.

Sample aggregator 608 can perform any of a variety of data cleansingoperations to identify and discard bad data samples. Several examples ofdata cleansing operations which can be performed by sample aggregator608 are described in U.S. patent application Ser. No. 13/631,301 filedSep. 28, 2012, the entire disclosure of which is incorporated byreference herein. In some embodiments, sample aggregator 608 performsthe data cleansing operations for raw data timeseries 704 beforegenerating the data rollup timeseries 706-714. This ensures that rawdata timeseries 704 used to generate data rollup timeseries 706-714 doesnot include any bad data samples. Accordingly, the data rolluptimeseries 706-714 do not need to be re-cleansed after the aggregationis performed.

Virtual Points

Referring again to FIG. 6, timeseries operators 606 are shown to includea virtual point calculator 610. Virtual point calculator 610 isconfigured to create virtual data points and calculate timeseries valuesfor the virtual data points. A virtual data point is a type ofcalculated data point derived from one or more actual data points. Insome embodiments, actual data points are measured data points, whereasvirtual data points are calculated data points. Virtual data points canbe used as substitutes for actual sensor data when the sensor datadesired for a particular application does not exist, but can becalculated from one or more actual data points. For example, a virtualdata point representing the enthalpy of a refrigerant can be calculatedusing actual data points measuring the temperature and pressure of therefrigerant. Virtual data points can also be used to provide timeseriesvalues for calculated quantities such as efficiency, coefficient ofperformance, and other variables that cannot be directly measured.

Virtual point calculator 610 can calculate virtual data points byapplying any of a variety of mathematical operations or functions toactual data points or other virtual data points. For example, virtualpoint calculator 610 can calculate a virtual data point (pointID₃) byadding two or more actual data points (pointID₁ and pointID₂) (e.g.,pointID₃=pointID₁+pointID₂). As another example, virtual pointcalculator 610 can calculate an enthalpy data point (pointID₄) based ona measured temperature data point (pointID₅) and a measured pressuredata point (pointID₆) (e.g., pointID₄=enthalpy(pointID₅, pointID₆)). Insome instances, a virtual data point can be derived from a single actualdata point. For example, virtual point calculator 610 can calculate asaturation temperature (pointID₇) of a known refrigerant based on ameasured refrigerant pressure (pointID₈) (e.g.,pointID₇=T_(sat)(pointID₈)). In general, virtual point calculator 610can calculate the timeseries values of a virtual data point using thetimeseries values of one or more actual data points and/or thetimeseries values of one or more other virtual data points.

In some embodiments, virtual point calculator 610 uses a set of virtualpoint rules to calculate the virtual data points. The virtual pointrules can define one or more input data points (e.g., actual or virtualdata points) and the mathematical operations that should be applied tothe input data point(s) to calculate each virtual data point. Thevirtual point rules can be provided by a user, received from an externalsystem or device, and/or stored in memory 510. Virtual point calculator610 can apply the set of virtual point rules to the timeseries values ofthe input data points to calculate timeseries values for the virtualdata points. The timeseries values for the virtual data points can bestored as derived timeseries data in local timeseries database 628and/or hosted timeseries database 636.

Virtual point calculator 610 can calculate virtual data points using thevalues of raw data timeseries 704 and/or the aggregated values of thedata rollup timeseries 706-714. In some embodiments, the input datapoints used to calculate a virtual data point are collected at differentsampling times and/or sampling rates. Accordingly, the samples of theinput data points may not be synchronized with each other, which canlead to ambiguity in which samples of the input data points should beused to calculate the virtual data point. Using the data rolluptimeseries 706-714 to calculate the virtual data points ensures that thetimestamps of the input data points are synchronized and eliminates anyambiguity in which data samples should be used.

Referring now to FIG. 8, several timeseries 800, 820, 840, and 860illustrating the synchronization of data samples resulting fromaggregating the raw timeseries data are shown, according to someembodiments. Timeseries 800 and 820 are raw data timeseries. Raw datatimeseries 800 has several raw data samples 802-810. Raw data sample 802is collected at time t₁; raw data sample 804 is collected at time t₂;raw data sample 806 is collected at time t₃; raw data sample 808 iscollected at time t₄; raw data sample 810 is collected at time t₅; andraw data sample 812 is collected at time t₆.

Raw data timeseries 820 also has several raw data samples 822, 824, 826,828, and 830. However, raw data samples, 822-830 are not synchronizedwith raw data samples 802-812. For example, raw data sample 822 iscollected before time t₁; raw data sample 824 is collected between timest₂ and t₃; raw data sample 826 is collected between times t₃ and t₄; rawdata sample 828 is collected between times t₄ and t₅; and raw datasample 830 is collected between times t₅ and t₆. The lack ofsynchronization between data samples 802-812 and raw data samples822-830 can lead to ambiguity in which of the data samples should beused together to calculate a virtual data point.

Timeseries 840 and 860 are data rollup timeseries. Data rolluptimeseries 840 can be generated by sample aggregator 608 by aggregatingraw data timeseries 800. Similarly, data rollup timeseries 860 can begenerated by sample aggregator 608 by aggregating raw data timeseries820. Both raw data timeseries 800 and 820 can be aggregated using thesame aggregation interval. Accordingly, the resulting data rolluptimeseries 840 and 860 have synchronized data samples. For example,aggregated data sample 842 is synchronized with aggregated data sample862 at time t₁′. Similarly, aggregated data sample 844 is synchronizedwith aggregated data sample 864 at time t₂′; aggregated data sample 846is synchronized with aggregated data sample 866 at time t₃′; andaggregated data sample 848 is synchronized with aggregated data sample868 at time t₄′.

The synchronization of data samples in data rollup timeseries 840 and860 allows virtual point calculator 610 to readily identify which of thedata samples should be used together to calculate a virtual point. Forexample, virtual point calculator 610 can identify which of the samplesof data rollup timeseries 840 and 860 have the same timestamp (e.g.,data samples 842 and 862, data samples 844 and 864, etc.). Virtual pointcalculator 610 can use two or more aggregated data samples with the sametimestamp to calculate a timeseries value of the virtual data point. Insome embodiments, virtual point calculator 610 assigns the sharedtimestamp of the input data samples to the timeseries value of thevirtual data point calculated from the input data samples.

Weather Points

Referring again to FIG. 6, timeseries operators 606 are shown to includea weather point calculator 612. Weather point calculator 612 isconfigured to perform weather-based calculations using the timeseriesdata. In some embodiments, weather point calculator 612 creates virtualdata points for weather-related variables such as cooling degree days(CDD), heating degree days (HDD), cooling energy days (CED), heatingenergy days (HED), and normalized energy consumption. The timeseriesvalues of the virtual data points calculated by weather point calculator612 can be stored as derived timeseries data in local timeseriesdatabase 628 and/or hosted timeseries database 636.

Weather point calculator 612 can calculate CDD by integrating thepositive temperature difference between the time-varying outdoor airtemperature T_(OA) and the cooling balance point T_(bC) for the buildingas shown in the following equation:CDD=∫^(period)max{0,(T _(OA) −T _(bC))}dtwhere period is the integration period. In some embodiments, the outdoorair temperature T_(OA) is a measured data point, whereas the coolingbalance point T_(bC) is a stored parameter. To calculate CDD for eachsample of the outdoor air temperature T_(OA), weather point calculator612 can multiply the quantity max{0, (T_(OA)−T_(bC))} by the samplingperiod Δt of the outdoor air temperature T_(OA). Weather pointcalculator 612 can calculate CED in a similar manner using outdoor airenthalpy E_(OA) instead of outdoor air temperature T_(OA). Outdoor airenthalpy E_(OA) can be a measured or virtual data point.

Weather point calculator 612 can calculate HDD by integrating thepositive temperature difference between a heating balance point T_(bH)for the building and the time-varying outdoor air temperature T_(OA) asshown in the following equation:HDD=∫^(period)max{0,(T _(bH) −T _(OA))}dtwhere period is the integration period. In some embodiments, the outdoorair temperature T_(OA) is a measured data point, whereas the heatingbalance point T_(bH) is a stored parameter. To calculate HDD for eachsample of the outdoor air temperature T_(OA), weather point calculator612 can multiply the quantity max{0, (T_(bH)−T_(OA))} by the samplingperiod Δt of the outdoor air temperature T_(OA). Weather pointcalculator 612 can calculate HED in a similar manner using outdoor airenthalpy E_(OA) instead of outdoor air temperature T_(OA).

In some embodiments, both virtual point calculator 610 and weather pointcalculator 612 calculate timeseries values of virtual data points.Weather point calculator 612 can calculate timeseries values of virtualdata points that depend on weather-related variables (e.g., outdoor airtemperature, outdoor air enthalpy, outdoor air humidity, outdoor lightintensity, precipitation, wind speed, etc.). Virtual point calculator610 can calculate timeseries values of virtual data points that dependon other types of variables (e.g., non-weather-related variables).Although only a few weather-related variables are described in detailhere, it is contemplated that weather point calculator 612 can calculatevirtual data points for any weather-related variable. Theweather-related data points used by weather point calculator 612 can bereceived as timeseries data from various weather sensors and/or from aweather service.

Fault Detection

Still referring to FIG. 6, timeseries operators 606 are shown to includea fault detector 614. Fault detector 614 can be configured to detectfaults in timeseries data. In some embodiments, fault detector 614performs fault detection for timeseries data representing meter data(e.g., measurements from a sensor) and/or for other types of timeseriesdata. Fault detector 614 can detect faults in the raw timeseries dataand/or the derived timeseries data. In some embodiments, fault detector614 receives fault detection rules from analytics service 524. Faultdetection rules can be defined by a user (e.g., via a rules editor) orreceived from an external system or device. In various embodiments, thefault detection rules can be stored within local storage 514 and/orhosted storage 516. Fault detector 614 can retrieve the fault detectionrules from local storage 514 or hosted storage 516 and can use the faultdetection rules to analyze the timeseries data.

In some embodiments, the fault detection rules provide criteria that canbe evaluated by fault detector 614 to detect faults in the timeseriesdata. For example, the fault detection rules can define a fault as adata value above or below a threshold value. As another example, thefault detection rules can define a fault as a data value outside apredetermined range of values. The threshold value and predeterminedrange of values can be based on the type of timeseries data (e.g., meterdata, calculated data, etc.), the type of variable represented by thetimeseries data (e.g., temperature, humidity, energy consumption, etc.),the system or device that measures or provides the timeseries data(e.g., a temperature sensor, a humidity sensor, a chiller, etc.), and/orother attributes of the timeseries data.

Fault detector 614 can apply the fault detection rules to the timeseriesdata to determine whether each sample of the timeseries data qualifiesas a fault. In some embodiments, fault detector 614 generates a faultdetection timeseries containing the results of the fault detection. Thefault detection timeseries can include a set of timeseries values, eachof which corresponds to a data sample of the timeseries data evaluatedby fault detector 614. In some embodiments, each timeseries value in thefault detection timeseries includes a timestamp and a fault detectionvalue. The timestamp can be the same as the timestamp of thecorresponding data sample of the data timeseries. The fault detectionvalue can indicate whether the corresponding data sample of the datatimeseries qualifies as a fault. For example, the fault detection valuecan have a value of “Fault” if a fault is detected and a value of “Notin Fault” if a fault is not detected in the corresponding data sample ofthe data timeseries. The fault detection timeseries can be stored inlocal timeseries database 628 and/or hosted timeseries database 636along with the raw timeseries data and the derived timeseries data.

Referring now to FIGS. 9A-9B, a block diagram and data table 900illustrating the fault detection timeseries is shown, according to someembodiments. In FIG. 9A, fault detector 614 is shown receiving a datatimeseries 902 from local storage 514 or hosted storage 516. Datatimeseries 902 can be a raw data timeseries or an derived datatimeseries. In some embodiments, data timeseries 902 is a timeseries ofvalues of an actual data point (e.g., a measured temperature). In otherembodiments, data timeseries 902 is a timeseries of values of a virtualdata point (e.g., a calculated efficiency). As shown in table 900, datatimeseries 902 includes a set of data samples. Each data sample includesa timestamp and a value. Most of the data samples have values within therange of 65-66. However, three of the data samples have values of 42.

Fault detector 614 can evaluate data timeseries 902 using a set of faultdetection rules to detect faults in data timeseries 902. In someembodiments, fault detector 614 determines that the data samples havingvalues of 42 qualify as faults according to the fault detection rules.Fault detector 614 can generate a fault detection timeseries 904containing the results of the fault detection. As shown in table 900,fault detection timeseries 904 includes a set of data samples. Like datatimeseries 902, each data sample of fault detection timeseries 904includes a timestamp and a value. Most of the values of fault detectiontimeseries 904 are shown as “Not in Fault,” indicating that no fault wasdetected for the corresponding sample of data timeseries 902 (i.e., thedata sample with the same timestamp). However, three of the data samplesin fault detection timeseries 904 have a value of “Fault,” indicatingthat the corresponding sample of data timeseries 902 qualifies as afault. As shown in FIG. 9A, fault detector 614 can store fault detectiontimeseries 904 in local storage 514 (e.g., in local timeseries database628) and/or hosted storage 516 (e.g., in hosted timeseries database 636)along with the raw timeseries data and the derived timeseries data.

Fault detection timeseries 904 can be used by BMS 500 to perform variousfault detection, diagnostic, and/or control processes. In someembodiments, fault detection timeseries 904 is further processed bytimeseries processing engine 604 to generate new timeseries derived fromfault detection timeseries 904. For example, sample aggregator 608 canuse fault detection timeseries 904 to generate a fault durationtimeseries. Sample aggregator 608 can aggregate multiple consecutivedata samples of fault detection timeseries 904 having the same datavalue into a single data sample. For example, sample aggregator 608 canaggregate the first two “Not in Fault” data samples of fault detectiontimeseries 904 into a single data sample representing a time periodduring which no fault was detected. Similarly, sample aggregator 608 canaggregate the final two “Fault” data samples of fault detectiontimeseries 904 into a single data sample representing a time periodduring which a fault was detected.

In some embodiments, each data sample in the fault duration timeserieshas a fault occurrence time and a fault duration. The fault occurrencetime can be indicated by the timestamp of the data sample in the faultduration timeseries. Sample aggregator 608 can set the timestamp of eachdata sample in the fault duration timeseries equal to the timestamp ofthe first data sample in the series of data samples in fault detectiontimeseries 904 which were aggregated to form the aggregated data sample.For example, if sample aggregator 608 aggregates the first two “Not inFault” data samples of fault detection timeseries 904, sample aggregator608 can set the timestamp of the aggregated data sample to2015-12-31T23: 10: 00. Similarly, if sample aggregator 608 aggregatesthe final two “Fault” data samples of fault detection timeseries 904,sample aggregator 608 can set the timestamp of the aggregated datasample to 2015-12-31T23: 50: 00.

The fault duration can be indicated by the value of the data sample inthe fault duration timeseries. Sample aggregator 608 can set the valueof each data sample in the fault duration timeseries equal to theduration spanned by the consecutive data samples in fault detectiontimeseries 904 which were aggregated to form the aggregated data sample.Sample aggregator 608 can calculate the duration spanned by multipleconsecutive data samples by subtracting the timestamp of the first datasample of fault detection timeseries 904 included in the aggregationfrom the timestamp of the next data sample of fault detection timeseries904 after the data samples included in the aggregation.

For example, if sample aggregator 608 aggregates the first two “Not inFault” data samples of fault detection timeseries 904, sample aggregator608 can calculate the duration of the aggregated data sample bysubtracting the timestamp 2015-12-31T23: 10: 00 (i.e., the timestamp ofthe first “Not in Fault” sample) from the timestamp 2015-12-31T23: 30:00 (i.e., the timestamp of the first “Fault” sample after theconsecutive “Not in Fault” samples) for an aggregated duration of twentyminutes. Similarly, if sample aggregator 608 aggregates the final two“Fault” data samples of fault detection timeseries 904, sampleaggregator 608 can calculate the duration of the aggregated data sampleby subtracting the timestamp 2015-12-31T23: 50: 00 (i.e., the timestampof the first “Fault” sample included in the aggregation) from thetimestamp 2016-01-01T00: 10: 00 (i.e., the timestamp of the first “Notin Fault” sample after the consecutive “Fault” samples) for anaggregated duration of twenty minutes.

Eventseries

Referring again to FIG. 6, timeseries operators 606 are shown to includean eventseries generator 615. Eventseries generator 615 can beconfigured to generate eventseries based on the raw data timeseriesand/or the derived data timeseries. Each eventseries may include aplurality of event samples that characterize various events and definethe start times and end times of the events. In the context ofeventseries, an “event” can be defined as a state or condition thatoccurs over a period of time. In other words, an event is not aninstantaneous occurrence, but rather is a non-instantaneous state orcondition observed over a time period having a non-zero duration (i.e.,having both a start time and a subsequent stop time). The state orcondition of the event can be based on the values of the timeseriessamples used to generate the eventseries. In some embodiments,eventseries generator 615 assigns a state to each timeseries samplebased on the value of the timeseries sample and then aggregates multipleconsecutive samples having the same state to define the time period overwhich that state is observed.

Eventseries generator 615 can be configured to assign a state to eachsample of an input timeseries (e.g., a raw data timeseries or a derivedtimeseries) by applying a set of rules to each sample. The process ofassigning a state to each sample of the input timeseries can bedescribed as an event-condition-action (ECA) process. ECA refers to thestructure of active rules in event driven architecture and activedatabase systems. For example, each rule in the set of rules may includean event, a condition, and an action. The event part of the rule mayspecify a signal that triggers invocation of the rule. The conditionpart of the rule may be a logical test (or series of logical tests)that, if satisfied or evaluates to true, causes the action to be carriedout. The action part of the rule may specify one or more actions to beperformed when the corresponding logical test is satisfied (e.g.,assigning a particular state to a sample of the input timeseries).

In some embodiments, the event part is the arrival of a new sample of aninput timeseries. Different rules may apply to different inputtimeseries. For example, the arrival of a new sample of a first inputtimeseries may qualify as a first event, whereas the arrival of a newsample of a second input timeseries may qualify as a second event.Eventseries generator 615 can use the identity of the input timeseriesto determine which event has occurred when a new sample of a particularinput timeseries is received. In other words, eventseries generator 615can select a particular rule to evaluate based on the identity of theinput timeseries.

In some embodiments, the condition includes one or more mathematicalchecks or logic statements that are evaluated by eventseries generator615. For example, evaluating the condition of a particular rule mayinclude comparing the value of the sample of the input timeseries to athreshold value. The condition may be satisfied if the value of thesample is less than the threshold value, equal to the threshold value,or greater than the threshold value, depending on the particular logicstatement specified by the condition. In some embodiments, the conditionincludes a series of mathematical checks that are performed byeventseries generator 615 in a predetermined order. Each mathematicalcheck may correspond to a different action to be performed if thatmathematical check is satisfied. For example, the conditions andcorresponding actions may be specified as follows:

  If Value > θ₁,Action = Action₁ Else If θ₁ ≥ Value > θ₂,Action =Action₂ Else If θ₂ ≥ Value > θ₃,Action = Action₃  Else If θ₃ ≥Value,Action = Action₄where Value is the value of the sample of the input timeseries, θ₁-θ₄are thresholds for the value, and Action₁-Action₄ are specific actionsthat are performed if the corresponding logic statement is satisfied.For example, Action₁ may be performed if the value of the sample isgreater than θ₁.

In some embodiments, the actions include assigning various states to thesample of the input timeseries. For example, Action₁ may includeassigning a first state to the sample of the input timeseries, whereasAction₂ may include assigning a second state to the sample of the inputtimeseries. Accordingly, different states can be assigned to the samplebased on the value of the sample relative to the threshold values. Eachtime a new sample of an input timeseries is received, eventseriesgenerator 615 can run through the set of rules, select the rules thatapply to that specific input timeseries, apply them in a predeterminedorder, determine which condition is satisfied, and assign a particularstate to the sample based on which condition is satisfied.

One example of an eventseries which can be generated by eventseriesgenerator 615 is an outdoor air temperature (OAT) eventseries. The OATeventseries may define one or more temperature states and may indicatethe time periods during which each of the temperature states isobserved. In some embodiments, the OAT eventseries is based on atimeseries of measurements of the OAT received as a raw data timeseries.Eventseries generator 615 can use a set of rules to assign a particulartemperature state (e.g., hot, warm, cool, cold) to each of thetimeseries OAT samples. For example, eventseries generator 615 can applythe following set of rules to the samples of an OAT timeseries:

   If OAT > 100,State = Hot Else If 100 ≥ OAT > 80,State = Warm  Else If80 ≥ OAT > 50,State = Cool   Else If 50 ≥ OAT,State = Coldwhere OAT is the value of a particular timeseries data sample. If theOAT is above 100, eventseries generator 615 can assign the timeseriessample to the “Hot” temperature state. If the OAT is less than or equalto 100 and greater than 80, eventseries generator 615 can assign thetimeseries sample to the “Warm” temperature state. If the OAT is lessthan or equal to 80 and greater than 50, eventseries generator 615 canassign the timeseries sample to the “Cool” temperature state. If the OATis less than or equal to 50, eventseries generator 615 can assign thetimeseries sample to the “Cold” temperature state.

In some embodiments, eventseries generator 615 creates a new timeseriesthat includes the assigned states for each sample of the original inputtimeseries. The new timeseries may be referred to as a “statetimeseries” because it indicates the state assigned to each timeseriessample. The state timeseries can be created by applying the set of rulesto an input timeseries as previously described. In some embodiments, thestate timeseries includes a state value and a timestamp for each sampleof the state timeseries. An example of a state timeseries is as follows:

-   -   [        state₁, timestamp₁        ,        state₂, timestamp₂        , . . .        state_(N), timestamp_(N)        ]        where state_(i) is the state assigned to the ith sample of the        input timeseries, timestamp_(i) is the timestamp of the ith        sample of the input timeseries, and N is the total number of        samples in the input timeseries. In some instances, two or more        of the state values may be the same if the same state is        assigned to multiple samples of the input timeseries.

In some embodiments, the state timeseries also includes the originalvalue of each sample of the input timeseries. For example, each sampleof the state timeseries may include a state value, a timestamp, and aninput data value, as shown in the following equation:

-   -   [        state₁, timestamp₁, value₁        , . . .        state_(N), timestamp_(N), value_(N)        ]        where value_(i) is the original value of the ith sample of the        input timeseries. The state timeseries is a type of derived        timeseries which can be stored and processed by timeseries        service 528.

Referring now to FIG. 9C, a table 910 illustrating the result ofassigning a temperature state to each timeseries sample is shown,according to some embodiments. Each timeseries sample is shown as aseparate row of table 910. The “Time” column of table 910 indicates thetimestamp associated with each sample, whereas the “OAT” column of table910 indicates the value of each timeseries sample. The “State” column oftable 910 indicates the state assigned to each timeseries sample byeventseries generator 615.

Referring now to FIG. 9D, a table 920 illustrating a set of eventsgenerated by eventseries generator 615 is shown, according to someembodiments. Each event is shown as a separate row of table 920. The“Event ID” column of table 920 indicates the unique identifier for eachevent (e.g., Event 1, Event 2, etc.). The “Start Time” column of table920 indicates the time at which each event begins and the “End Time”column of table 920 indicates the time at which event ends. The “State”column of table 920 indicates the state associated with each event.

Eventseries generator 615 can generate each event shown in table 920 byidentifying consecutive timeseries samples with the same assigned stateand determining a time period that includes the identified samples. Insome embodiments, the time period starts at the timestamp of the firstsample having a given state and ends immediately before the timestamp ofthe next sample having a different state. For example, the first twotimeseries samples shown in table 910 both have the state “Cold,”whereas the third sample in table 910 has the state “Cool.” Eventseriesgenerator 615 can identify the first two samples as having the samestate and can generate the time period 00:00-01:59 which includes bothof the identified samples. This time period begins at the timestamp ofthe first sample (i.e., 00:00) and ends immediately before the timestampof the third sample (i.e., 02:00). Eventseries generator 615 can createan event for each group of consecutive samples having the same state.

Eventseries generator 615 can perform a similar analysis for theremaining timeseries samples in table 910 to generate each of the eventsshown in table 920. In some instances, multiple events can have the samestate associated therewith. For example, both Event 1 and Event 7 shownin table 920 have the “Cold” state. Similarly, both Event 2 and Event 6have the “Cool” state and both Event 3 and Event 5 have the “Warm”state. It should be noted that an event defines not only a particularstate, but also a time period (i.e., a series of consecutive timesamples) during which that state is observed. If the same state isobserved during multiple non-consecutive time periods, multiple eventshaving the same state can be generated to represent each of thenon-consecutive time periods.

In some embodiments, eventseries generator 615 creates an eventseriesfor a set of events. An eventseries is conceptually similar to atimeseries in that both represent a series of occurrences. However, thesamples of a timeseries correspond to instantaneous occurrences having asingle timestamp, whereas the samples of an eventseries correspond tonon-instantaneous events having both a start time and a stop time. Forexample, eventseries generator 615 may create the following eventseriesfor the set of events shown in table 920:

-   -   [        ID=1, State=Cold, StartTime=00:00, EndTime=01; 59        ,        -   ID=2, State=Cool, StartTime=02: 00, EndTime=08; 59            ,        -   ID=3, State=Warm, StartTime=09: 00, EndTime=11; 59            ,        -   ID=4, State=Hot, StartTime=12: 00, EndTime=15; 59            ,        -   ID=5, State=Warm, StartTime=16: 00, EndTime=18; 59            ,        -   ID=6, State=Cool, StartTime=19: 00, EndTime=21; 59            ,        -   ID=7, State=Cold, StartTime=22: 00, EndTime=23; 59            ,]            where each item within the bent brackets            is an event having the attributes ID, State, StartTime, and            EndTime. Events can be stored in a tabular format (as shown            in FIG. 9D), as a text string (as shown above), as a data            object (e.g., a JSON object), in a container format, or any            of a variety of formats.            Eventseries Updates—Streaming Data

Table 920 shown in FIG. 9D represents the final set of events for thetime period ranging from 00:00-23:59. In some embodiments, the events intable 920 are generated after all of the timeseries samples within thetime period have been collected. However, eventseries generator 615 canalso generate and update events in real time as the data samples arecollected. This functionality allows eventseries generator 615 to updateevents and/or eventseries in real time upon receiving individual samplesof incoming streaming data.

Referring now to FIGS. 9E-9H, several tables illustrating howeventseries generator 615 can update an eventseries in real time uponreceiving new samples of streaming data are shown, according to someembodiments. FIG. 9E shows table 910 broken into five segments. The topsegment includes all of the data samples received up to time t₁ andidentifies the state associated with each data sample. At time t₁,eventseries generator 615 can translate the information in table 910into table 921 shown in FIG. 9F. At time t₁, the most recent data sample(i.e., the sample with timestamp 15:00) was associated with the “Hot”temperature state, which indicates that the “Hot” temperature state isstill active. The end time of the “Hot” temperature state cannot bedetermined based on the information known at time t₁. Accordingly, table921 is shown to include a value of “Null” as the end time of Event 4.

At time t₂, eventseries generator 615 receives the next sample of theOAT timeseries. This sample has a timestamp of 16:00 and is associatedwith the “Warm” state. At time t₂, eventseries generator 615 candetermine that the “Hot” state is no longer active and the system hastransitioned into the “Warm” state. Accordingly, eventseries generator615 can update table 921 to create table 922 shown in FIG. 9G. In table922, the “Null” value at the end time of Event 4 is updated with theactual end time of Event 4 (i.e., 15:59). Eventseries generator 615 canalso add a new event (i.e., Event 5) to table 922 to represent the newevent associated with the current “Warm” state. Event 5 has a start timeof 16:00 and an end time of “Null” since the actual end time of Event 5is unknown given the information known at time t₂.

At times t₃ and t₄, eventseries generator 615 receives the next twosamples of the OAT timeseries. These samples have timestamps of 17:00and 18:00 and both are associated with the “Warm” state. Eventseriesgenerator 615 does not need to update table 922 at times t₃ and t₄ sincethe new samples indicate that Event 5 is still active and has not yetended. Accordingly, the end time of Event 5 remains “Null” and the“Warm” state is still the most recent state.

At time t₅, eventseries generator 615 receives the next sample of theOAT timeseries. This sample has a timestamp of 19:00 and is associatedwith the “Cool” state. At time t₅, eventseries generator 615 candetermine that the “Warm” state is no longer active and the system hastransitioned into the “Cool” state. Accordingly, eventseries generator615 can update table 922 to create table 923 shown in FIG. 9H. In table923, the “Null” value at the end time of Event 5 is updated with theactual end time of Event 5 (i.e., 18:59). Eventseries generator 615 canalso add a new event (i.e., Event 6) to table 925 to represent the newevent associated with the current “Cool” state. Event 6 has a start timeof 19:00 and an end time of “Null” since the actual end time of Event 6is unknown given the information known at time t₅.

Eventseries Updates—Out of Order Data

The above scenario assumes that each incoming sample of the timeseriesdata is received in the correct order (i.e., with monotonicallyincreasing timestamps). However, eventseries generator 615 can also beconfigured to update events and eventseries if the incoming samples arereceived out of order. The following scenarios illustrate howeventseries generator 615 can handle out of order data.

Scenario A

Referring now to FIGS. 9I-9M, several tables illustrating howeventseries generator 615 can update an eventseries in real time whenincoming data samples are received out of order are shown, according tosome embodiments. In this scenario, the data sample having timestamp16:00 is received after the data sample having timestamp 17:00. FIG. 9Ishows table 910 broken into five segments. The top segment includes allof the data samples received up to time t₁ and identifies the stateassociated with each data sample. At time t₁, eventseries generator 615can translate the information in table 910 into table 931 shown in FIG.9J. At time t₁, the most recent data sample (i.e., the sample withtimestamp 15:00) was associated with the “Hot” temperature state, whichindicates that the “Hot” temperature state is still active. The end timeof the “Hot” temperature state cannot be determined based on theinformation known at time t₁. Accordingly, table 931 is shown to includea value of “Null” as the end time of Event 4.

At time t₂, eventseries generator 615 receives another sample of the OATtimeseries. This sample has a timestamp of 17:00 and is associated withthe “Warm” state. At time t₂, eventseries generator 615 can determinethat the “Hot” state is no longer active and the system has transitionedinto the “Warm” state. Accordingly, eventseries generator 615 can updatetable 931 to create table 932 shown in FIG. 9K. In table 932, the “Null”value at the end time of Event 4 is updated with the estimated end timeof Event 4 (i.e., 16:59). It should be noted that this end time is notthe actual end time, but rather the best estimate given the informationknown up to time t₂. The actual end time of Event 4 may have occurredanytime between timestamp 15:00 and timestamp 17:00. Eventseriesgenerator 615 can also add a new event (i.e., Event 5) to table 932 torepresent the new event associated with the current “Warm” state. Event5 has a start time of 17:00 and an end time of “Null” since the actualend time of Event 5 is unknown given the information known at time t₂.

At time t₃, eventseries generator 615 receives another sample of the OATtimeseries. This sample has a timestamp of 16:00 and is associated withthe “Warm” state. At time t₃, eventseries generator 615 can determinethat the estimated end time of Event 4 (i.e., 16:59) and the start timeof Event 5 need to be updated based on the information provided by thesample received at time t₃. Specifically, eventseries generator 615 canupdate the end time of Event 4 to 15:59 and can update the start time ofEvent 5 to 16:00, as shown in table 933 in FIG. 9L. Since the end timeof Event 5 cannot be determined based on the information known at timet₃, the end time of Event 5 may remain “Null.”

At time t₄, eventseries generator 615 receives the next sample of theOAT timeseries. This sample has a timestamp of 18:00 and is associatedwith the “Warm” state. Eventseries generator 615 does not need to updatetable 933 at time t₄ since the new samples indicate that Event 5 isstill active and has not yet ended. Accordingly, the end time of Event 5remains “Null” and the “Warm” state is still the most recent state.

At time t₅, eventseries generator 615 receives the next sample of theOAT timeseries. This sample has a timestamp of 19:00 and is associatedwith the “Cool” state. At time t₅, eventseries generator 615 candetermine that the “Warm” state is no longer active and the system hastransitioned into the “Cool” state. Accordingly, eventseries generator615 can update table 933 to create table 935 shown in FIG. 9H. In table923, the “Null” value at the end time of Event 5 is updated with theactual end time of Event 5 (i.e., 18:59). Eventseries generator 615 canalso add a new event (i.e., Event 6) to table 935 to represent the newevent associated with the current “Cool” state. Event 6 has a start timeof 19:00 and an end time of “Null” since the actual end time of Event 6is unknown given the information known at time t₅.

Scenario B

Referring now to FIGS. 9N-9R, several tables illustrating anotherexample of how eventseries generator 615 can update an eventseries inreal time when incoming data samples are received out of order areshown, according to some embodiments. In this scenario, the data samplehaving timestamp 16:00 is received after the data sample havingtimestamp 19:00. FIG. 9N shows table 910 broken into five segments. Thetop segment includes all of the data samples received up to time t₁ andidentifies the state associated with each data sample. At time t₁,eventseries generator 615 can translate the information in table 910into table 941 shown in FIG. 9O. At time t₁, the most recent data sample(i.e., the sample with timestamp 15:00) was associated with the “Hot”temperature state, which indicates that the “Hot” temperature state isstill active. The end time of the “Hot” temperature state cannot bedetermined based on the information known at time t₁. Accordingly, table941 is shown to include a value of “Null” as the end time of Event 4.

At time t₂, eventseries generator 615 receives another sample of the OATtimeseries. This sample has a timestamp of 17:00 and is associated withthe “Warm” state. At time t₂, eventseries generator 615 can determinethat the “Hot” state is no longer active and the system has transitionedinto the “Warm” state. Accordingly, eventseries generator 615 can updatetable 941 to create table 942 shown in FIG. 9P. In table 942, the “Null”value at the end time of Event 4 is updated with the estimated end timeof Event 4 (i.e., 16:59). It should be noted that this end time is notthe actual end time, but rather the best estimate given the informationknown up to time t₂. The actual end time of Event 4 may have occurredanytime between timestamp 15:00 and timestamp 17:00. Eventseriesgenerator 615 can also add a new event (i.e., Event 5) to table 942 torepresent the new event associated with the current “Warm” state. Event5 has a start time of 17:00 and an end time of “Null” since the actualend time of Event 5 is unknown given the information known at time t₂.

At time t₃, eventseries generator 615 receives the next sample of theOAT timeseries. This sample has a timestamp of 18:00 and is associatedwith the “Warm” state. Eventseries generator 615 does not need to updatetable 942 at time t₃ since the new samples indicate that Event 5 isstill active and has not yet ended. Accordingly, the end time of Event 5remains “Null” and the “Warm” state is still the most recent state.

At time t₄, eventseries generator 615 receives the next sample of theOAT timeseries. This sample has a timestamp of 19:00 and is associatedwith the “Cool” state. At time t₄, eventseries generator 615 candetermine that the “Warm” state is no longer active and the system hastransitioned into the “Cool” state. Accordingly, eventseries generator615 can update table 942 to create table 944 shown in FIG. 9Q. In table944, the “Null” value at the end time of Event 5 is updated with theactual end time of Event 5 (i.e., 18:59). Eventseries generator 615 canalso add a new event (i.e., Event 6) to table 944 to represent the newevent associated with the current “Cool” state. Event 6 has a start timeof 19:00 and an end time of “Null” since the actual end time of Event 6is unknown given the information known at time t₄.

At time t₅, eventseries generator 615 receives another sample of the OATtimeseries. This sample has a timestamp of 16:00 and is associated withthe “Warm” state. At time t₄, eventseries generator 615 can determinethat the estimated end time of Event 4 (i.e., 16:59) and the start timeof Event 5 need to be updated based on the information provided by thesample received at time t₃. Specifically, eventseries generator 615 canupdate the end time of Event 4 to 15:59 and can update the start time ofEvent 5 to 16:00, as shown in table 945 in FIG. 9R. Since the end timeof Event 6 cannot be determined based on the information known at timet₅, the end time of Event 6 may remain “Null.”

Scenario C

Referring now to FIGS. 9S-9Y, several tables illustrating anotherexample of how eventseries generator 615 can update an eventseries inreal time when incoming data samples are received out of order areshown, according to some embodiments. In this scenario, the data samplesare received in the order shown in FIGS. 9S and 9W. The data sampleswith timestamps 00:00-11:00 are received in the correct order. However,the next three samples received have timestamps 17:00, 18:00, and 19:00.The next sample received has timestamp 15:00, followed by the sampleswith timestamps 12:00 and 13:00. The final two samples received havetimestamps 16:00 and 14:00.

FIG. 9S shows table 910 broken into five segments. The top segmentincludes all of the data samples received up to time t₁ and identifiesthe state associated with each data sample. At time t₁, eventseriesgenerator 615 can translate the information in table 910 into table 951shown in FIG. 9T. At time t₁, the most recent data sample (i.e., thesample with timestamp 11:00) was associated with the “Warm” temperaturestate, which indicates that the “Warm” temperature state is stillactive. The end time of the “Warm” temperature state cannot bedetermined based on the information known at time t₁. Accordingly, table951 is shown to include a value of “Null” as the end time of Event 3.

At time t₂, eventseries generator 615 receives another sample of the OATtimeseries. This sample has a timestamp of 17:00 and is associated withthe “Warm” state. Although a complete picture of the timeseries datawould show that the system has transitioned into the “Hot” state andthen back into the “Warm” state, the information received up to time t₂indicates (incorrectly) that the system has remained in the “Warm” statefrom 11:00 to 17:00. Accordingly, eventseries generator 615 determinesthat the system is still in the “Warm” state at time t₂ and does notupdate table 951. The sample received with timestamp 18:00 alsoindicates that the system is still in the “Warm” state and does nottrigger an update.

At time t₃, eventseries generator 615 receives another sample of the OATtimeseries. This sample has a timestamp of 19:00 and is associated withthe “Cool” state. At time t₃, eventseries generator 615 can determinethat the “Warm” state is no longer active and the system hastransitioned into the “Cool” state. Accordingly, eventseries generator615 can update table 951 to create table 953 shown in FIG. 9U. In table953, the “Null” value at the end time of Event 3 is updated with theestimated end time of Event 3 (i.e., 18:59). This end time is not theactual end time, but rather the best estimate given the informationknown up to time t₃. The actual end time of Event 3 may have occurredanytime between timestamp 09:00 and timestamp 19:00. Eventseriesgenerator 615 can also add a new event (i.e., Event 4) to table 953 torepresent the new event associated with the current “Cool” state. Event4 has a start time of 19:00 and an end time of “Null” since the actualend time of Event 4 is unknown given the information known at time t₃.

At time t₄, eventseries generator 615 receives the next sample of theOAT timeseries. This sample has a timestamp of 15:00 and is associatedwith the “Hot” state. At time t₄, eventseries generator 615 candetermine that the time period associated with Event 3 is actually threeseparate events (i.e., two “Warm” events with a “Hot” event in between).Accordingly, eventseries generator 615 can update table 953 to createtable 954 shown in FIG. 9V. In table 954, the end time of Event 3 isupdated to 14:59 and a new event (i.e., Event 5) is added to representthe time period during which the “Hot” state was active. Event 5 has astart time of 15:00 and an end time of 16:59. Another new event (i.e.,Event 6) is added to represent the second “Warm” time period which waspreviously part of Event 3. Event 6 has a start time of 17:00 and an endtime of 18:59. The events shown in table 954 are arranged in temporalorder rather than in the order of the event ID.

At time t₅, eventseries generator 615 receives another sample of the OATtimeseries. This sample has a timestamp of 12:00 and is associated withthe “Hot” state. At time t₅, eventseries generator 615 can determinethat the estimated end time of Event 3 (i.e., 14:59) and the estimatedstart time of Event 5 (i.e., 15:00) need to be updated based on theinformation provided by the sample received at time t₅. Specifically,eventseries generator 615 can update the end time of Event 3 to 11:59and can update the start time of Event 5 to 12:00, as shown in table 955in FIG. 9X. Since the end time of Event 4 cannot be determined based onthe information known at time t₅, the end time of Event 6 may remain“Null.”

At time t₆, eventseries generator 615 receives another sample of the OATtimeseries. This sample has a timestamp of 16:00 and is associated withthe “Warm” state. At time t₆, eventseries generator 615 can determinethat the estimated end time of Event 5 (i.e., 16:59) and the estimatedstart time of Event 6 (i.e., 16:00) need to be updated based on theinformation provided by the sample received at time t₆. Specifically,eventseries generator 615 can update the end time of Event 5 to 15:59and can update the start time of Event 6 to 16:00, as shown in table 956in FIG. 9Y. Since the end time of Event 4 still cannot be determinedbased on the information known at time t₆, the end time of Event 6 mayremain “Null.”

Eventseries Process

Referring now to FIG. 9Z, a flowchart of a process 960 for creating andupdating eventseries is shown, according to some embodiments. Process960 can be performed by eventseries generator 615, as described withreference to FIGS. 6 and 9C-9Y. In some embodiments, process 960 isperformed to create an eventseries based on the samples of a datatimeseries. Process 960 can be performed after all of the samples of thedata timeseries have been collected or can be performed each time a newsample of the data timeseries is collected.

Process 960 is shown to include obtaining a new sample of a datatimeseries (step 962) and assigning a state to the sample using a set ofrules (step 964). In some embodiments, the sample is obtained from asensor configured to measure a variable of interest in or around abuilding. For example, the sample can be a sample of a raw datatimeseries. In other embodiments, the sample is a sample of a deriveddata timeseries generated by sample aggregator 608, virtual pointcalculator 610, weather point calculator 612, or other timeseriesoperators 606. The sample can be obtained from a set of samples of acomplete timeseries or can be received as the latest sample of anincoming data stream.

In some embodiments, step 964 includes applying a set of rules to thesample of the data timeseries to determine which state to assign. Theset of rules may define various ranges of values and a correspondingstate for each range of values. Step 964 can include assigning thesample to a particular state if the value of the value of the sample iswithin the corresponding range of values. For example, if the sample isa sample of outdoor air temperature (OAT), the set of rules may definevarious temperature ranges and a temperature state for each of thetemperature ranges. One example of such a set of rules is as follows:

   If OAT > 100,State = Hot Else If 100 ≥ OAT > 80,State = Warm  Else If80 ≥ OAT > 50,State = Cool   Else If 50 ≥ OAT,State = Coldwhere OAT is the value of a particular timeseries data sample. If theOAT is above 100, the sample can be assigned to the “Hot” temperaturestate. If the OAT is less than or equal to 100 and greater than 80, thesample can be assigned to the “Warm” temperature state. If the OAT isless than or equal to 80 and greater than 50, the sample can be assignedto the “Cool” temperature state. If the OAT is less than or equal to 50,the sample can be assigned to the “Cold” temperature state.

Still referring to FIG. 9Z, process 960 is shown to include determiningwhether the sample is part of an existing event (step 966). Step 966 mayinclude identifying all of the events in an existing eventseries anddetermining whether the sample belongs to any of the identified events.Each event may be defined by the combination of a particular state and atime period having both a start time and an end time. Step 966 mayinclude determining that the sample is part of an existing event if thesample is both (1) assigned to the same state as the existing event and(2) has a timestamp that is either (a) within the time period associatedwith the existing event or (b) consecutive with the time periodassociated with the existing event. However, step 966 may includedetermining that the sample is not part of an existing event if thesample does not have the same state as the existing event or does nothave a timestamp that that is either within the time period associatedwith the existing event or consecutive with the time period associatedwith the existing event.

In step 966, a timestamp may be considered within the time periodassociated with an existing event if the timestamp is between the starttime of the event and the end time of the event. A timestamp may beconsidered consecutive with the time period associated with an existingevent if the timestamp is immediately before the start time orimmediately after the end time of the event. For example, if a newsample has a timestamp before the start time of an event and no othersamples have intervening timestamps between the timestamp of the newsample and the start time of the event, the timestamp may be consideredconsecutive with the time period associated with the existing event.Similarly, if a new sample has a timestamp after the end time of anevent and no other samples have intervening timestamps between the endtime of the event and the timestamp of the new sample, the timestamp maybe considered consecutive with the time period associated with theexisting event.

If the new sample is part of an existing event (i.e., the result of step966 is “yes”), process 960 may proceed to determining whether the newsample extends the existing event (step 968). Step 968 may includedetermining whether the timestamp of the new sample is consecutive withthe time period associated with the existing event (i.e., immediatelybefore the start time of the event or immediately after the end time ofthe event). If the timestamp of the new sample is consecutive with thetime period associated with the existing event, step 968 may includedetermining that the sample extends the existing event. However, if thetimestamp of the new sample is not consecutive with the time periodassociated with the existing event, step 968 may include determiningthat the sample does not extend the existing event.

If the sample does not extend the existing event (i.e., the result ofstep 968 is “no”), process 960 may include determining that no update tothe existing event is needed. This situation may occur when thetimestamp of the new sample is between the start time of the existingevent and the end time of the existing event (i.e., within the timeperiod associated with the existing event). Since the time periodassociated with the existing event already covers the timestamp of thenew sample, it may be unnecessary to update the existing event toinclude the timestamp of the new sample.

However, if the sample extends the existing event (i.e., the result ofstep 968 is “yes”), process 960 may proceed to updating the start timeor end time of the existing event based on the timestamp of the sample(step 972). Step 972 may include moving the start time of the eventbackward in time or moving the end time of the event forward in timesuch that the time period between the start time and the end timeincludes the timestamp of the new sample. For example, if the timestampof the sample is before the start time of the event, step 972 mayinclude replacing the start time of the existing event with thetimestamp of the sample.

Similarly, if the timestamp of the sample is after the end time of theevent, step 972 may include replacing the end time of the existing eventwith a new end time that occurs after the timestamp of the sample. Forexample, if the existing event has an original end time of 04:59 and thenew sample has a timestamp of 05:00, step 972 may include updating theend time of the event to 05:59 (or any other time that occurs after05:00) such that the adjusted time period associated with the eventincludes the timestamp of the new sample. If the original end time ofthe existing event is “Null” and the new sample extends the end time ofthe existing event, step 972 may maintain the original end time of“Null.” This situation is described in greater detail with reference toFIGS. 9E-9H.

Returning to step 966, if the sample is not part of an existing event(i.e., the result of step 966 is “no”), process 960 may proceed tocreating a new event based on the state and the timestamp of the newsample (step 974). The new event may have a state that matches the stateassigned to the new sample in step 964. The new event may have a starttime equal to the timestamp of the sample and an end time that occursafter the timestamp of the sample such that the time period associatedwith the new event includes the timestamp of the sample. The end timemay have a value of “Null” if the new event is the last event in theeventseries or a non-null value of the new event is not the last eventin the eventseries. For example, if the next event in the timeseriesbegins at timestamp 06:00, step 974 may include setting the end time ofthe new event to 05:59.

After creating the new event in step 974, process 960 may perform steps976-988 to update other events in the eventseries based on the newinformation provided by the new event. For example, if the new event isthe last event in the eventseries (i.e., the result of step 976 is“yes”), process 960 may update the end time of the previous event (i.e.,the event that occurs immediately before the new event) (step 978). Theupdate performed in step 978 may include setting the end time of theprevious event to a time immediately before the timestamp of the newsample. For example, if the new sample has a timestamp of 05:00, step978 may include updating the end time of the previous event to 04:59. Ifthe new event is not the last event in the eventseries (i.e., the resultof step 976 is “no”), process 960 may proceed to step 980.

If the new event occurs between existing events in the eventseries(i.e., the result of step 980 is “yes”), process 960 may update the endtime of the previous event (step 982). The update performed in step 982may be the same as the update performed in step 978. For example, theupdate performed in step 982 may include setting the end time of theprevious event to a time immediately before the timestamp of the newsample. If the new event does not occur between existing events in theeventseries (i.e., the result of step 980 is “no”), process 960 mayproceed to step 984.

If the new event splits an existing event in the eventseries (i.e., theresult of step 984 is “yes”), process 960 may split the existing eventinto two events with the new event in between. In some embodiments,splitting the existing event into two events includes updating the endtime of the existing event to end before the new event (step 986) andcreating a second new event beginning after the first new event andending at the previous end time of the existing event (step 988). Forexample, consider a situation in which the existing event has a starttime of 04:00, an end time of 11:59, and a state of “Warm.” The newevent added in step 974 may have a start time of 08:00, an end time of08:59, and a state of “Hot.” Accordingly, step 986 may include changingthe end time of the existing event to 07:59 such that the existing eventcorresponds to a first “Warm” event and covers the time period from04:00 to 07:59. The intervening “Hot” event may cover the time periodfrom 08:00 to 08:59. The second new event created in step 988 (i.e., thesecond “Warm” event) may have a start time of 09:00 and an end time of11:59. The state of the second new event may be the same as the state ofthe existing event.

Properties of Events and Eventseries

Similar to timeseries, an eventseries can be used in two ways. In someembodiments, an event series is used for storage only. For example,events can be created by an external application and stored in aneventseries. In this scenario, the eventseries is used only as a storagecontainer. In other embodiments, eventseries can be used for bothstorage and processing. For example, events can be created byeventseries generator 615 based on raw or derived timeseries by applyinga set of rules, as previously described. In this scenario, theeventseries is both the storage container and the mechanism for creatingthe events.

In some embodiments, each eventseries includes the following propertiesor attributes: EventseriesID, OrgID, InputTimeseriesID,StateTimeseriesID, Rules, and Status. The EventseriesID property may bea unique ID generated by eventseries generator 615 when a neweventseries is created. The EventseriesID property can be used touniquely identify the eventseries and distinguish the eventseries fromother eventseries. The OrgID property may identify the organization(e.g., “ABC Corporation”) to which the eventseries belongs. Similar totimeseries, each eventseries may belong to a particular organization,building, facility, or other entity (described in greater detail withreference to FIGS. 11A-11B).

The InputTimeseriesID property may identify the timeseries used tocreate the eventseries. For example, if the eventseries is a series ofoutdoor air temperature (OAT) events, the InputTimeseriesID property mayidentify the OAT timeseries from which the OAT eventseries is generated.In some embodiments, the input timeseries has the following format:

-   -   [<key, timestamp₁, value₁>, <key, timestamp₂, value₂>, <key,        timestamp₃, value₃>]        where key is an identifier of the source of the data samples        (e.g., timeseries ID, sensor ID, etc.), timestamp_(i) identifies        a time associated with the ith sample, and value_(i) indicates        the value of the ith sample.

The Rules property may identify a list of rules that are applied to theinput timeseries to assign a particular state to each sample of theinput timeseries. In some embodiments, the list of rules includes aplurality of rules that are applied in a particular order. The order maybe defined by the logical structure of the rules. For example, the rulesmay include a set of “If” and “Elself” statements that are evaluated inthe order in which the statements appear in the set of rules. An exampleof a set of rules is as follows:

   If OAT > 100,State = Hot Else If 100 ≥ OAT > 80,State = Warm  Else If80 ≥ OAT > 50,State = Cool   Else If 50 ≥ OAT,State = Cold

The StateTimeseriesID property may identify the state timeseries inwhich the assigned states are stored. The state timeseries can becreated by applying the set of rules to an input timeseries aspreviously described. In some embodiments, the state timeseries includesa state value and a timestamp for each sample of the state timeseries.An example of a state timeseries is as follows:

-   -   [        state₁, timestamp₁        ,        state₂, timestamp₂        , . . .        state_(N), timestamp_(N)        ]        where state_(i) is the state assigned to the ith sample of the        input timeseries, timestamp_(i) is the timestamp of the ith        sample of the input timeseries, and N is the total number of        samples in the input timeseries.

The Status property may indicate whether the eventseries is active(i.e., Status=Active) or inactive (i.e., Status=Inactive). In someembodiments, an eventseries is active by default when the eventseries iscreated. An eventseries can be deactivated by events service 603. Eventsservice 603 can change the Status property from active to inactive upondeactivating an eventseries.

Each eventseries may include a set of events. Each event may include thefollowing properties: EventID, State, StartTimestamp, EndTimestamp, andEventseriesID. The EventID property may be a unique ID generated byeventseries generator 615 when a new event is created. The EventIDproperty can be used to uniquely identify a particular event anddistinguish the event from other events in the eventseries. The Stateproperty may be a text string that defines the state associated with theevent. Each event may be uniquely associated with one state. TheStartTimestamp property may indicate the start time of the event,whereas the EndTimestamp property may indicate the end time of theevent. The StartTimestamp and EndTimestamp properties may be timestampsin any of a variety of formats (e.g., 2017-01-01T00:00:00). TheEventseriesID property may identify the eventseries which includes theevent. The EventseriesID property may be the same unique identifier usedto identify and distinguish eventseries from each other.

Event Service

Referring again to FIG. 6, timeseries service 528 is shown to include anevent service 603. In some embodiments, event service 603 is part oftimeseries service 528. In other embodiments, event service 603 is aseparate service (i.e., separate from timeseries service 528) withindata platform services 520. Event service 603 can be configured toreceive and process requests for information relating to various eventsand eventseries. Event service 603 can also create and update events andeventseries in response to a request from an application or a user.Several examples of how event service 603 can handle requests aredescribed below. The following table identifies the types of actionsevent service 603 can perform with respect to events and eventseries:

GET POST PUT Resource (read) (create) (update) /Eventseries RetrieveCreate one N/A list of or more new Eventseries Eventseries/Eventseries/{eventseriesId} Read a Create a Update the specificspecific specific Eventseries Eventseries Eventseries /Events RetrieveCreate one N/A a list of or more new Events Events /Events/{evenId} Reada Create a Update the specific specific specific Event Event Event

Event service 603 can be configured to create a new eventseries inresponse to a request containing an OrgID attribute and a processingtype attribute. For example, event service 603 can receive the followingrequest:

Post {timeseriesV2}/eventseries/new {    “orgId”: “Abc Inc”,   “ProcessingType” : “none” }where “Abc Inc” is the ID of the organization to which the neweventseries will belong and no processing type is specified.

In response to this request, event service 603 can create a neweventseries (i.e., an empty eventseries container) and assign anEventseriesID to the eventseries. For example, event service 603 canrespond to the request as follows:

{   “eventseriesId”: “c7c157e4-603f-4b25-b182-ce7b0f8291d8”,   “orgId”:“Abc Inc”,   “inputTimeseriesId”: null,   “stateTimeseriesId”: null,  “rules”: null,   “status”: “active”,   “processingType”: “stream” }

In some embodiments, event service 603 is configured to create a neweventseries in response to a request containing an OrgID attribute, anInputTimeseriesID attribute, a StateTimeseriesID attribute, and a Rulesattribute. For example, event service 603 can receive the followingrequest:

{   “orgId”: “Abc Inc”,   “inputTimeseriesId”:“793c156e4-603f-4b2e-bt82-ce7b0f829uj3”,   “stateTimeseriesId”:“uic157e4-6r2f-4b25-b682-ct7b0f8917u”,   “rules”: [    {“compareOp”:“Gt”, “scalar”: 100, “state”: “Hot”},    {“compareOp”: “Gt”, “scalar”:80, “state”: “Warm”},    {“compareOp”: “Gt”, “scalar”: 50, “state”:“Cool”},    {“compareOp”: “Lte”, “scalar”: 50, “state”: “Cold”}   ] }where “793c156e4-603f-4b2e-bt82-ce7b0f829uj3” is the ID of the inputtimeseries used to generate the eventseries,“uic157e4-6r2f-4b25-b682-ct7b0f82917u” is the ID of the state timeseriescontaining the states assigned to each sample of the input timeseries,and the “rules” attribute contains a set of rules used to assign a stateto each sample of the input timeseries.

In response to this request, event service 603 can create a neweventseries (i.e., an empty eventseries container) and assign anEventseriesID to the eventseries. For example, event service 603 canrespond to the request as follows:

{   “eventseriesId”: “c7c157e4-603f-4b25-b182-ce7b0f8291d8”,   “orgId”:“Abc Inc”,   “inputTimeseriesId”:“793c156e4-603f-4b2e-bt82-ce7b0f829uj3”,   “stateTimeseriesId”:“uic157e4-6r2f-4b25-b682-ct7b0f82917u”,   “rules”: [    {“compareOp”:“Gt”, “scalar”: 100, “state”: “Hot”},    {“compareOp”: “Gt”, “scalar”:80, “state”: “Warm”},    {“compareOp”: “Gt”, “scalar”: 50, “state”:“Cool”},    {“compareOp”: “Lte”, “scalar”: 50, “state”: “Cold”}   ],  “status”: “active”,   “processingType”: “stream” }

In some embodiments, event service 603 is configured to add new eventsto an existing eventseries. For example, event service 603 can receive arequest to add a new event to an eventseries. The request may specifythe EventseriesID, the start time of the event, the end time of theevent, and the state associated with the event, as shown in thefollowing request:

Post{timeseriesV2}/eventseries/c7c157e4-603f-4b25-b182-ce7b0f8291d8/events

[  {   “eventseriesId”: “c7c157e4-603f-4b25-b182-ce7b0f8291d8”,  “startTimestamp”: “2017-04-01 13:48:23-05:00”,   “endTimestamp”:“2017-04-01 13:54:11-05:00”,   “state”: “High Pressure Alarm”  } ]

In response to this request, event service 603 can generate a newEventID for the new event and can add the new event to the eventseriesdesignated by the EventseriesID “c7c157e4-603f-4b25-b182-ce7b0f8291d8.”The new event may have the start time “2017-04-01 13:48:23-05:00,” theend time “2017-04-01 13:54:11-05:00,” and the state “High PressureAlarm” as specified in the request. In some embodiments, event service603 responds to the request by acknowledging that the new event has beenadded to the eventseries.

In some embodiments, event service 603 is configured to update existingevents in an eventseries. For example, event service 603 can receive arequest to add update one or more properties of an existing event in aneventseries. The request may specify the EventseriesID, the updatedstart time of the event, the updated end time of the event, and/or theupdated state associated with the event, as shown in the followingrequest:

Put{timeseriesV2}/eventseries/c7c157e4-603f-4b25-b182-ce7b0f8291d8/events/c7c157e4-603f-4b25-b182-ce7b0f8291d8

{   “eventseriesId”: “c7c157e4-603f-4b25-b182-ce7b0f8291d8”,  “startTimestamp”: “2017-04-01 13:48:23-05:00”,   “endTimestamp”:“2017-04-01 13:54:11-05:00”,   “state”: “High Pressure Alarm” }

In response to this request, event service 603 can update the specifiedproperties of the event designated by EventseriesID“c7c157e4-603f-4b25-b182-ce7b0f8291d8.” The updated event may have thestart time “2017-04-01 13:48:23-05:00,” the end time “2017-04-0113:54:11-05:00,” and the state “High Pressure Alarm” as specified in therequest. In some embodiments, event service 603 responds to the requestby acknowledging that the event has been updated.

In some embodiments, event service 603 is configured to read the eventsof an eventseries. For example, event service 603 can receive a requestto identify all of the events associated with an eventseries. Therequest may be specified as a get request as follows:

Get {timeseriesV2}/eventseries/c7c157e4-603f-4b25-b182-ce7b0M91d8/events

where “c7c157e4-603f-4b25-b182-ce7b0f8291d8” is the EventseriesID of aspecific eventseries.

In response to this request, event service 603 can search for all eventsof the specified eventseries and can return a list of the identifiedevents. An example response which can be provided by event service 603is as follows:

[   {     “eventid”: “g9c197e4-003f-4u25-b182-se7b0f81945y”,    “eventseriesId”: “c7c157e4-603f-4b25-b182-ce7b0f8291d8”,    “startTimestamp”: “2017-04-01 13:48:23-05:00”,       “endTimestamp”:“2017-04-01 13:54:11-05:00”,       “state”: “High Pressure Alarm”   } ]where “g9c197e4-003f-4u25-b182-se7b0f81945y” is the EventID of anidentified event matching the search parameters. The response mayspecify the EventseriesID, StartTimestamp, EndTimestamp, and Stateproperties of each identified event.

In some embodiments, event service 603 is configured to search for theevents of an eventseries that have a specific state. For example, eventservice 603 can receive a request to identify all of the eventsassociated with a particular eventseries which have a specific state.The request may be specified as a get request as follows:

Get{timeseriesV2}/eventseries/c7c157e4-603f-4b25-b182-ce7b0f8291d8/events?state=Hot

where “c7c157e4-603f-4b25-b182-ce7b0f8291d8” is the EventseriesID of aparticular eventseries and “state=Hot” specifies that the search shouldreturn only events of the eventseries that have the state “Hot.” Inresponse to this request, event service 603 may search for all matchingevents (i.e., events of the specified eventseries that have thespecified state) and may return a list of events that match the searchparameters.

In some embodiments, event service 603 is configured to search for theevents of an eventseries that have a start time or end time matching agiven value. For example, event service 603 can receive a request toidentify all of the events of a particular eventseries that have a starttime or end time that matches a specified timestamp. The request may bespecified as a get request as follows:

Get {timeseriesV2}/eventseries/c7c157e4-603f-4b25-b182-ce7b0f8291d8/events?startTime=2017-04-01%2010:00:00-05:00&endTime=2017-04-01%2010:00:00-05:00

where “c7c157e4-603f-4b25-b182-ce7b0f8291d8” is the EventseriesID of aparticular eventseries and the “startTime” and “endTime” parametersspecify the start time and end time of the event. In response to thisrequest, event service 603 may search for all matching events (i.e.,(startTimestamp of event<startTime and endTimestamp of event>endTime)and may return a list of events that match the search parameters.

In some embodiments, event service 603 is configured to search for theevents of an eventseries that have a time range overlapping (at leastpartially) with a specified time range. For example, event service 603can receive a request to identify all of the events of a particulareventseries that have (1) an event start time before a specified starttime and an event end time after the specified start time or (2) anevent start time before a specified end time and an event end time afterthe specified end time. The request may be specified as a get request asfollows:

Get{timeseriesV2}/eventseries/c7c157e4-603f-4b25-b182-ce7b0f8291d8/events?startTime=2017-04-01%2010:00:00-05:00&endTime=2017-04-01%2011:59:00-05:00

where “c7c157e4-603f-4b25-b182-ce7b0f8291d8” is the EventseriesID of aparticular eventseries and the “startTime” and “endTime” parametersspecify the start time and end time of the event. In response to thisrequest, event service 603 may search for all events that match thefollowing criteria:[(startTimestamp of event<startTime of query) AND (endTimestamp ofevent>startTime of query)] OR [(startTimestamp of event<endTime ofquery) AND (endTimestamp of event>endTime of query)]and may return a list of events that match these criteria.

In some embodiments, event service 603 is configured to search forevents of an eventseries that have a specific state and a time rangethat overlaps (at least partially) with a given time range. For example,event service 603 can receive a request to identify all of the events ofa particular eventseries that have a particular state and either (1) anevent start time before a specified start time and an event end timeafter the specified start time or (2) an event start time before aspecified end time and an event end time after the specified end time.The request may be specified as a get request as follows:

Get{timeseriesV2}/eventseries/c7c157e4-603f-4b25-b182-ce7b0f8291d8/events?state=Hot&startTime=2017-04-01%2010:00:00-05:00&endTime=2017-04-01%2011:59:00-05:00

where “c7c157e4-603f-4b25-b182-ce7b0f8291d8” is the EventseriesID of aparticular eventseries, the “state” parameter specifies a particularstate, and the “startTime” and “endTime” parameters specify the starttime and end time of the event. In response to this request, eventservice 603 may search for all events that match the following criteria:State=Hot AND[(startTimestamp of event<startTime of query) AND (endTimestamp ofevent>startTime of query)] OR [(startTimestamp of event<endTime ofquery) AND (endTimestamp of event>endTime of query)]and may return a list of events that match these criteria.Directed Acyclic Graphs

Referring again to FIG. 6, timeseries processing engine 604 is shown toinclude a directed acyclic graph (DAG) generator 620. DAG generator 620can be configured to generate one or more DAGs for each raw datatimeseries. Each DAG may define a workflow or sequence of operationswhich can be performed by timeseries operators 606 on the raw datatimeseries. When new samples of the raw data timeseries are received,workflow manager 622 can retrieve the corresponding DAG and use the DAGto determine how the raw data timeseries should be processed. In someembodiments, the DAGs are declarative views which represent the sequenceof operations applied to each raw data timeseries. The DAGs may bedesigned for timeseries rather than structured query language (SQL).

In some embodiments, DAGs apply over windows of time. For example, thetimeseries processing operations defined by a DAG may include a dataaggregation operation that aggregates a plurality of raw data sampleshaving timestamps within a given time window. The start time and endtime of the time window may be defined by the DAG and the timeseries towhich the DAG is applied. The DAG may define the duration of the timewindow over which the data aggregation operation will be performed. Forexample, the DAG may define the aggregation operation as an hourlyaggregation (i.e., to produce an hourly data rollup timeseries), a dailyaggregation (i.e., to produce a daily data rollup timeseries), a weeklyaggregation (i.e., to produce a weekly data rollup timeseries), or anyother aggregation duration. The position of the time window (e.g., aspecific day, a specific week, etc.) over which the aggregation isperformed may be defined by the timestamps of the data samples oftimeseries provided as an input to the DAG.

In operation, sample aggregator 608 can use the DAG to identify theduration of the time window (e.g., an hour, a day, a week, etc.) overwhich the data aggregation operation will be performed. Sampleaggregator 608 can use the timestamps of the data samples in thetimeseries provided as an input to the DAG to identify the location ofthe time window (i.e., the start time and the end time). Sampleaggregator 608 can set the start time and end time of the time windowsuch that the time window has the identified duration and includes thetimestamps of the data samples. In some embodiments, the time windowsare fixed, having predefined start times and end times (e.g., thebeginning and end of each hour, day, week, etc.). In other embodiments,the time windows may be sliding time windows, having start times and endtimes that depend on the timestamps of the data samples in the inputtimeseries.

Referring now to FIG. 10A, an example of a DAG 1000 which can be createdby DAG generator 620 is shown, according to an exemplary embodiment. DAG1000 is shown as a structured tree representing a graph of the dataflowrather than a formal scripting language. Blocks 1002 and 1004 representthe input timeseries which can be specified by timeseries ID (e.g., ID123, ID 456, etc.). Blocks 1006 and 1008 are functional blocksrepresenting data cleansing operations. Similarly, block 1010 is afunctional block representing a weekly rollup aggregation and block 1012is a functional block representing an addition operation. Blocks 1014and 1016 represent storage operations indicating where the output of DAG1000 should be stored (e.g., local storage, hosted storage, etc.).

In DAG 1000, the arrows connecting blocks 1002-1016 represent the flowof data and indicate the sequence in which the operations defined by thefunctional blocks should be performed. For example, the cleansingoperation represented by block 1006 will be the first operationperformed on the timeseries represented by block 1002. The output of thecleansing operation in block 1006 will then be provided as an input toboth the aggregation operation represented by block 1010 and theaddition operation represented by block 1012. Similarly, the cleansingoperation represented by block 1008 will be the first operationperformed on the timeseries represented by block 1004. The output of thecleansing operation in block 1008 will then be provided as an input tothe addition operation represented by block 1012.

In some embodiments, DAG 1000 can reference other DAGs as inputs.Timeseries processing engine 604 can stitch the DAGs together intolarger groups. DAG 1000 can support both scalar operators (e.g., runthis function on this sample at this timestamp) and aggregate windowoperators (e.g., apply this function over all the values in thetimeseries from this time window). The time windows can be arbitrary andare not limited to fixed aggregation windows. Logical operators can beused to express rules and implement fault detection algorithms. In someembodiments, DAG 1000 supports user-defined functions and user-definedaggregates.

In some embodiments, DAG 1000 is created based on user input. A user candrag-and-drop various input blocks 1002-1004, functional blocks1006-1012, and output blocks 1014-1016 into DAG 1000 and connect themwith arrows to define a sequence of operations. The user can edit theoperations to define various parameters of the operations. For example,the user can define parameters such as upper and lower bounds for thedata cleansing operations in blocks 1006-1008 and an aggregationinterval for the aggregation operation in block 1010. DAG 1000 can becreated and edited in a graphical drag-and-drop flow editor withoutrequiring the user to write or edit any formal code. In someembodiments, DAG generator 620 is configured to automatically generatethe formal code used by timeseries operators 606 based on DAG 1000.

Referring now to FIG. 10B, an example of code 1050 which can begenerated by DAG generator 620 is shown, according to an exemplaryembodiment. Code 1050 is shown as a collection of JSON objects 1052-1056that represent the various operations defined by DAG 1000. Each JSONobject corresponds to one of the functional blocks in DAG 1000 andspecifies the inputs/sources, the computation, and the outputs of eachblock. For example, object 1052 corresponds to the cleansing operationrepresented by block 1006 and defines the input timeseries (i.e.,“123_Raw”), the particular cleansing operation to be performed (i.e.,“BoundsLimitingCleanseOP”), the parameters of the cleansing operation(i.e., “upperbound” and “lowerbound”) and the outputs of the cleansingoperation (i.e., “123_Cleanse” and “BLCleanseFlag”).

Similarly, object 1054 corresponds to the aggregation operationrepresented by block 1010 and defines the input timeseries (i.e.,“123_Cleanse”), the aggregation operation to be performed (i.e.,“AggregateOP”), the parameter of the aggregation operation (i.e.,“interval”: “week”) and the output of the aggregation operation (i.e.,“123_WeeklyRollup”). Object 1056 corresponds to the addition operationrepresented by block 1012 and defines the input timeseries (i.e.,“123_Cleanse” and “456_Cleanse”), the addition operation to be performed(i.e., “AddOP”), and the output of the addition operation (i.e.,“123+456”). Although not specifically shown in FIG. 10B, code 1050 mayinclude an object for each functional block in DAG 1000.

Advantageously, the declarative views defined by the DAGs provide acomprehensive view of the operations applied to various inputtimeseries. This provides flexibility to run the workflow defined by aDAG at query time (e.g., when a request for derived timeseries data isreceived) or prior to query time (e.g., when new raw data samples arereceived, in response to a defined event or trigger, etc.). Thisflexibility allows timeseries processing engine 604 to perform some orall of their operations ahead of time and/or in response to a requestfor specific derived data timeseries.

Referring again to FIG. 6, timeseries processing engine 604 is shown toinclude a DAG optimizer 618. DAG optimizer 618 can be configured tocombine multiple DAGs or multiple steps of a DAG to improve theefficiency of the operations performed by timeseries operators 606. Forexample, suppose that a DAG has one functional block which adds“Timeseries A” and “Timeseries B” to create “Timeseries C” (i.e., A+B=C)and another functional block which adds “Timeseries C” and “TimeseriesD” to create “Timeseries E” (i.e., C+D=E). DAG optimizer 618 can combinethese two functional blocks into a single functional block whichcomputes “Timeseries E” directly from “Timeseries A,” “Timeseries B,”and “Timeseries D” (i.e., E=A+B+D). Alternatively, both “Timeseries C”and “Timeseries E” can be computed in the same functional block toreduce the number of independent operations required to process the DAG.

In some embodiments, DAG optimizer 618 combines DAGs or steps of a DAGin response to a determination that multiple DAGs or steps of a DAG willuse similar or shared inputs (e.g., one or more of the same inputtimeseries). This allows the inputs to be retrieved and loaded oncerather than performing two separate operations that both load the sameinputs. In some embodiments, DAG optimizer 618 schedules timeseriesoperators 606 to nodes where data is resident in memory in order tofurther reduce the amount of data required to be loaded from timeseriesdatabases 628 and 636.

Entity Graph

Referring now to FIG. 11A, an entity graph 1100 is shown, according tosome embodiments. In some embodiments, entity graph 1100 is generated orused by data collector 512, as described with reference to FIG. 5.Entity graph 1100 describes how a building is organized and how thedifferent systems and spaces within the building relate to each other.For example, entity graph 1100 is shown to include an organization 1102,a space 1104, a system 1106, a point 1108, and a timeseries 1109. Thearrows interconnecting organization 1102, space 1104, system 1106, point1108, and timeseries 1109 identify the relationships between suchentities. In some embodiments, the relationships are stored asattributes of the entity described by the attribute.

Organization 1102 is shown to include a contains descendants attribute1110, a parent ancestors attribute 1112, a contains attribute 1114, alocated in attribute 1116, an occupied by ancestors attribute 1118, andan occupies by attribute 1122. The contains descendants attribute 1110identifies any descendant entities contained within organization 1102.The parent ancestors attribute 1112 identifies any parent entities toorganization 1102. The contains attribute 1114 identifies any otherorganizations contained within organization 1102. The asterisk alongsidethe contains attribute 1114 indicates that organization 1102 can containany number of other organizations. The located in attribute 1116identifies another organization within which organization 1102 islocated. The number 1 alongside the located in attribute 1116 indicatesthat organization 1102 can be located in exactly one other organization.The occupies attribute 1122 identifies any spaces occupied byorganization 1102. The asterisk alongside the occupies attribute 1122indicates that organization 1102 can occupy any number of spaces.

Space 1104 is shown to include an occupied by attribute 1120, anoccupied by ancestors attribute 1118, a contains space descendantsattribute 1124, a located in ancestors attribute 1126, a contains spacesattribute 1128, a located in attribute 1130, a served by systemsattribute 1138, and a served by system descendants attribute 1134. Theoccupied by attribute 1120 identifies an organization occupied by space1104. The number 1 alongside the occupied by attribute 1120 indicatesthat space 1104 can be occupied by exactly one organization. Theoccupied by ancestors attribute 1118 identifies one or more ancestors toorganization 1102 that are occupied by space 1104. The asteriskalongside the occupied by ancestors attribute 1118 indicates that space1104 can be occupied by any number of ancestors.

The contains space descendants attribute 1124 identifies any descendantsto space 1104 that are contained within space 1104. The located inancestors attribute 1126 identifies any ancestors to space 1104 withinwhich space 1104 is located. The contains spaces attribute 1128identifies any other spaces contained within space 1104. The asteriskalongside the contains spaces attribute 1128 indicates that space 1104can contain any number of other spaces. The located in attribute 1130identifies another space within which space 1104 is located. The number1 alongside the located in attribute 1130 indicates that space 1104 canbe located in exactly one other space. The served by systems attribute1138 identifies any systems that serve space 1104. The asteriskalongside the served by systems attribute 1138 indicates that space 1104can be served by any number of systems. The served by system descendantsattribute 1134 identifies any descendent systems that serve space 1104.The asterisk alongside the served by descendant systems attribute 1134indicates that space 1104 can be served by any number of descendantsystems.

System 1106 is shown to include a serves spaces attribute 1136, a servesspace ancestors attribute 1132, a subsystem descendants attribute 1140,a part of ancestors attribute 1142, a subsystems attribute 1144, a partof attribute 1146, and a points attribute 1150. The serves spacesattribute 1136 identifies any spaces that are served by system 1106. Theasterisk alongside the serves spaces attribute 1136 indicates thatsystem 1106 can serve any number of spaces. The serves space ancestorsattribute 1132 identifies any ancestors to space 1104 that are served bysystem 1106. The asterisk alongside the serves ancestor spaces attribute1132 indicates that system 1106 can serve any number of ancestor spaces.

The subsystem descendants attribute 1140 identifies any subsystemdescendants of other systems contained within system 1106. The part ofancestors attribute 1142 identifies any ancestors to system 1106 thatsystem 1106 is part of. The subsystems attribute 1144 identifies anysubsystems contained within system 1106. The asterisk alongside thesubsystems attribute 1144 indicates that system 1106 can contain anynumber of subsystems. The part of attribute 1146 identifies any othersystems that system 1106 is part of. The number 1 alongside the part ofattribute 1146 indicates that system 1106 can be part of exactly oneother system. The points attribute 1150 identifies any data points thatare associated with system 1106. The asterisk alongside the pointsattribute 1150 indicates that any number of data points can beassociated with system 1106.

Point 1108 is shown to include a used by system attribute 1148. Theasterisk alongside the used by system attribute 1148 indicates thatpoint 1108 can be used by any number of systems. Point 1108 is alsoshown to include a used by timeseries attribute 1154. The asteriskalongside the used by timeseries attribute 1154 indicates that point1108 can be used by any number of timeseries (e.g., raw data timeseriesvirtual point timeseries, data rollup timeseries, etc.). For example,multiple virtual point timeseries can be based on the same actual datapoint 1108. In some embodiments, the used by timeseries attribute 1154is treated as a list of timeseries that subscribe to changes in value ofdata point 1108. When the value of point 1108 changes, the timeserieslisted in the used by timeseries attribute 1154 can be identified andautomatically updated to reflect the changed value of point 1108.

Timeseries 1109 is shown to include a uses point attribute 1152. Theasterisk alongside the uses point attribute 1152 indicates thattimeseries 1109 can use any number of actual data points. For example, avirtual point timeseries can be based on multiple actual data points. Insome embodiments, the uses point attribute 1152 is treated as a list ofpoints to monitor for changes in value. When any of the pointsidentified by the uses point attribute 1152 are updated, timeseries 1109can be automatically updated to reflect the changed value of the pointsused by timeseries 1109.

Timeseries 1109 is also shown to include a used by timeseries attribute1156 and a uses timeseries attribute 1158. The asterisks alongside theused by timeseries attribute 1156 and the uses timeseries attribute 1158indicate that timeseries 1109 can be used by any number of othertimeseries and can use any number of other timeseries. For example, botha data rollup timeseries and a virtual point timeseries can be based onthe same raw data timeseries. As another example, a single virtual pointtimeseries can be based on multiple other timeseries (e.g., multiple rawdata timeseries). In some embodiments, the used by timeseries attribute1156 is treated as a list of timeseries that subscribe to updates intimeseries 1109. When timeseries 1109 is updated, the timeseries listedin the used by timeseries attribute 1156 can be identified andautomatically updated to reflect the change to timeseries 1109.Similarly, the uses timeseries attribute 1158 can be treated as a listof timeseries to monitor for updates. When any of the timeseriesidentified by the uses timeseries attribute 1158 are updated, timeseries1109 can be automatically updated to reflect the updates to the othertimeseries upon which timeseries 1109 is based.

Referring now to FIG. 11B, an example of an entity graph 1160 for aparticular building management system is shown, according to someembodiments. Entity graph 1160 is shown to include an organization 1161(“ACME Corp”). Organization 1161 be a collection of people, a legalentity, a business, an agency, or other type of organization.Organization 1161 occupies space 1163 (“Milwaukee Campus”), as indicatedby the occupies attribute 1164. Space 1163 is occupied by organization1161, as indicated by the occupied by attribute 1162.

In some embodiments, space 1163 is a top level space in a hierarchy ofspaces. For example, space 1163 can represent an entire campus (i.e., acollection of buildings). Space 1163 can contain various subspaces(e.g., individual buildings) such as space 1165 (“Building 1”) and space1173 (“Building 2”), as indicated by the contains attributes 1168 and1180. Spaces 1165 and 1180 are located in space 1163, as indicated bythe located in attribute 1166. Each of spaces 1165 and 1173 can containlower level subspaces such as individual floors, zones, or rooms withineach building. However, such subspaces are omitted from entity graph1160 for simplicity.

Space 1165 is served by system 1167 (“ElecMainMeter1”) as indicated bythe served by attribute 1172. System 1167 can be any system that servesspace 1165 (e.g., a HVAC system, a lighting system, an electricalsystem, a security system, etc.). The serves attribute 1170 indicatesthat system 1167 serves space 1165. In entity graph 1160, system 1167 isshown as an electrical system having a subsystem 1169(“LightingSubMeter1”) and a subsystem 1171 (“PlugLoadSubMeter2”) asindicated by the subsystem attributes 1176 and 1178. Subsystems 1169 and1171 are part of system 1167, as indicated by the part of attribute1174.

Space 1173 is served by system 1175 (“ElecMainMeter2”) as indicated bythe served by attribute 1184. System 1175 can be any system that servesspace 1173 (e.g., a HVAC system, a lighting system, an electricalsystem, a security system, etc.). The serves attribute 1182 indicatesthat system 1175 serves space 1173. In entity graph 1160, system 1175 isshown as an electrical system having a subsystem 1177(“LightingSubMeter3”) as indicated by the subsystem attribute 1188.Subsystem 1177 is part of system 1175, as indicated by the part ofattribute 1186.

In addition to the attributes shown in FIG. 11B, entity graph 1160 caninclude “ancestors” and “descendants” attributes on each entity in thehierarchy. The ancestors attribute can identify (e.g., in a flat list)all of the entities that are ancestors to a given entity. For example,the ancestors attribute for space 1165 may identify both space 1163 andorganization 1161 as ancestors. Similarly, the descendants attribute canidentify all (e.g., in a flat list) of the entities that are descendantsof a given entity. For example, the descendants attribute for space 1165may identify system 1167, subsystem 1169, and subsystem 1171 asdescendants. This provides each entity with a complete listing of itsancestors and descendants, regardless of how many levels are included inthe hierarchical tree. This is a form of transitive closure.

In some embodiments, the transitive closure provided by the descendantsand ancestors attributes allows entity graph 1160 to facilitate simplequeries without having to search multiple levels of the hierarchicaltree. For example, the following query can be used to find all metersunder the Milwaukee Campus space 1163:

-   -   /Systems?$filter=(systemType eq Jci.Be.Data.SystemType‘Meter’)        and ancestorSpaces/any(a:a/name eq ‘Milwaukee Campus’)        and can be answered using only the descendants attribute of the        Milwaukee Campus space 1163. For example, the descendants        attribute of space 1163 can identify all meters that are        hierarchically below space 1163. The descendants attribute can        be organized as a flat list and stored as an attribute of space        1163. This allows the query to be served by searching only the        descendants attribute of space 1163 without requiring other        levels or entities of the hierarchy to be searched.

Referring now to FIG. 12, an object relationship diagram 1200 is shown,according to some embodiments. Relationship diagram 1200 is shown toinclude an entity template 1202, a point 1204, a timeseries 1206, and asample 1208. In some embodiments, entity template 1202, point 1204,timeseries 1206, and sample 1208 are stored as data objects withinmemory 510, local storage 514, and/or hosted storage 516. Relationshipdiagram 1200 illustrates the relationships between entity template 1202,point 1204, and timeseries 1206.

Entity template 1202 can include various attributes such as an IDattribute, a name attribute, a properties attribute, and a relationshipsattribute. The ID attribute can be provided as a text string andidentifies a unique ID for entity template 1202. The name attribute canalso be provided as a text string and identifies the name of entitytemplate 1202. The properties attribute can be provided as a vector andidentifies one or more properties of entity template 1202. Therelationships attribute can also be provided as a vector and identifiesone or more relationships of entity template 1202.

Point 1204 can include various attributes such as an ID attribute, anentity template ID attribute, a timeseries attribute, and a units IDattribute. The ID attribute can be provided as a text string andidentifies a unique ID for point 1204. The entity template ID attributecan also be provided as a text string and identifies the entity template1202 associated with point 1204 (e.g., by listing the ID attribute ofentity template 1202). Any number of points 1204 can be associated withentity template 1202. However, in some embodiments, each point 1204 isassociated with a single entity template 1202. The timeseries attributecan be provided as a text string and identifies any timeseriesassociated with point 1204 (e.g., by listing the ID string of anytimeseries 1206 associated with point 1204). The units ID attribute canalso be provided as a text string and identifies the units of thevariable quantified by point 1204.

Timeseries 1206 can include various attributes such as an ID attribute,a samples attribute, a transformation type attribute, and a units IDattribute. The ID attribute can be provided as a text string andidentifies a unique ID for timeseries 1206. The unique ID of timeseries1206 can be listed in the timeseries attribute of point 1204 toassociate timeseries 1206 with point 1204. Any number of timeseries 1206can be associated with point 1204. Each timeseries 1206 is associatedwith a single point 1204. The samples attribute can be provided as avector and identifies one or more samples associated with timeseries1206. The transformation type attribute identifies the type oftransformation used to generate timeseries 1206 (e.g., average hourly,average daily, average monthly, etc.). The units ID attribute can alsobe provided as a text string and identifies the units of the variablequantified by timeseries 1206.

Sample 1208 can include a timestamp attribute and a value attribute. Thetimestamp attribute can be provided in local time and can include anoffset relative to universal time. The value attribute can include adata value of sample 1208. In some instances, the value attribute is anumerical value (e.g., for measured variables). In other instances, thevalue attribute can be a text string such as “Fault” if sample 1208 ispart of a fault detection timeseries.

Timeseries Processing Workflow

Referring now to FIG. 13A, a block diagram illustrating a timeseriesprocessing workflow 1300 is shown, according to an exemplary embodiment.Workflow 1300 may be performed by workflow manager 622 in combinationwith other components of timeseries service 528. Workflow 1300 is shownto include performing a read of the timeseries data (step 1302). Step1302 may include reading raw data samples and/or the derived datasamples provided by timeseries storage interface 616. The timeseriesdata may be stored in local storage 514 or hosted storage 516. In someembodiments, local storage 514 includes on-site data storage (e.g.,Redis, PostgreSQL, etc.). Hosted storage 516 may include cloud datastorage (e.g., Azure Redis, DocDB, HBase, etc.).

Timeseries storage interface 616 can be configured to read and write atimeseries collection, a samples collection, and a post sample request(PSR) collection. Each of these collections can be stored in localstorage 514 and/or hosted storage 516. The timeseries collection maycontain all the timeseries registered in workflow manager 622. Thetimeseries collection may also contain the DAG for each timeseries. Thetimeseries collection can be used by workflow manager 622 to accept onlyPSRs related to valid timeseries registered in workflow manager 622. Thetimeseries collection can also be used in steps 1314-1316 to lookup theDAG for a specific timeseries ID.

In some embodiments, the entire timeseries collection is loaded intolocal memory. The timeseries collection can be a regular collection or apartitioned collection (e.g., one partition for approximately every 100timeseries). In some embodiments, the timeseries collection containsabout 200,000 to 250,000 timeseries. The ID for each document in thetimeseries collection may be the timeseries ID. The DAG for eachtimeseries may contain a set of operations and/or transformations thatneed to be performed to generate the derived timeseries data based onthe timeseries. On registration of a new timeseries, the DAG for thetimeseries can be selected from DAG templates. The DAG template mayinclude a set of standard operations applicable to the timeseries. Ondefinition of a new metric for a timeseries, the new metric and the listof operations to generate that metric can be added to the DAG.

The samples collection may contain all of the timeseries samples (e.g.,raw samples, derived timeseries samples). The samples collection can beused for all GET requests for a specific timeseries ID. A portion of thesamples collection can be stored in local memory (e.g., past 48 hours)whereas the remainder of the samples collection can be stored in localstorage 514 or hosted storage 516. The samples collection may act as apartitioned collection instead of a regular collection to improveefficiency and performance. In some embodiments, the samples collectionis stored in a JSON format and partitioned on timeseries ID. The IDfield may be unique for each partition and may have the form “Metric:Timestamp.”

The PSR collection may contain all of the PSRs and can be used toprovide status updates to the user for a PSR related to a specifictimeseries ID. A portion of the PSR collection can be stored in localmemory (e.g., past 48 hours) whereas the remainder of the PSR collectioncan be stored in local storage 514 or hosted storage 516. The PSRcollection can be partitioned on timeseries ID. In some embodiments, theID for each document in the PSR collection has the form “TimeseriesID:Timestamp.”

Still referring to FIG. 13A, workflow 1300 is shown to include acceptinga PSR (step 1304). Step 1304 may be performed by executing a PSRprocess. In some embodiments, the PSR process receives a PSR anddetermines whether the PSR contains more than one timeseries ID. Inresponse to a determination that the PSR contains more than onetimeseries ID, the PSR process may break the PSR into multiple PSRs,each of which is limited to a single timeseries ID. The PSRs can beprovided to PSR event hub 1306. PSR event hub 1306 can be configured tostore PSR events. Each PSR event may include a PSR for one timeseriesID. In some embodiments, each PSR event is stored in the form“TimeseriesID: Timestamp.”

Workflow 1300 is shown to include deduplicating raw samples (step 1308).Step 1308 may be performed by executing a deduplication process. In someembodiments, the deduplication process includes accepting PSR eventsfrom PSR event hub 1306 and splitting each PSR into a list of samples.Step 1308 may include tagging each sample as a new sample, an updatedsample, or a duplicate sample. New samples and updated samples can besent to raw samples event hub 1310, whereas duplicate samples may bediscarded. In some embodiments, step 1308 is deployed on Azure usingAzure Worker Roles. Step 1308 can include checking for duplicate samplesin local storage 514 and hosted storage 516 as well as the samples thatare currently in raw samples event hub 1310.

In some embodiments, the deduplication process in step 1308 removes allduplicate data samples such that only a single unique copy of each datasample remains. Removing all duplicate samples may ensure that aggregateoperations produce accurate aggregate values. In other embodiments, thededuplication process in step 1308 is configured to remove most, but notall, duplicate samples. For example, the deduplication process can beimplemented using a Bloom filter, which allows for the possibility offalse positives but not false negatives. In step 1308, a false positivecan be defined as a non-duplicate new or updated sample. Accordingly,some duplicates may be flagged as non-duplicate, which introduces thepossibility that some duplicate samples may not be properly identifiedand removed. The deduplicated raw samples can be sent to raw samplesevent hub 1310.

Workflow 1300 is shown to include storing the raw samples (step 1312).Step 1312 can include accepting the raw samples from raw samples eventhub 1310 and pushing the raw samples to persistent storage. In someembodiments, step 1312 is deployed on Azure using Azure Worker Roles.The worker role may generate requests at a rate based on X % of thecapacity of the storage. For example, if the capacity of the storage is10,000 RU and X % is 20% (e.g., 20% of the storage throughput isreserved for raw sample writes), and each write takes 5 RU, step 1312may generate a total of 400 writes per second

$\left( {{i.e.},{\frac{10,000*20\%}{5} = 400}} \right).$

Workflow 1300 is shown to include generating an event trigger DAG (step1314). Step 1314 can be performed by executing an event trigger DAGprocess. Step 1314 may include accepting events (samples) from rawsamples event hub 1310. For each sample event, step 1314 may includeidentifying the timeseries ID of the sample and accessing the timeseriescollection to obtain the DAG for the corresponding timeseries. Step 1314may include identifying each derived data timeseries generated by theDAG and each operation included in the DAG. In some embodiments, step1314 tags each operation to indicate whether the operation should besent to the C# engine 1332 or the Python engine 1334 for execution. Step1314 may include identifying and fetching any additional data (e.g.,samples, timeseries, parameters, etc.) which may be necessary to performthe operations defined by the DAG. Step 1314 may generate an enrichedDAG which includes the original DAG along with all the data necessary toperform the operations defined by the DAG. The enriched DAG can be sentto the DAG event hub 1318.

In some embodiments, workflow 1300 includes generating a clock triggerDAG (step 1316). Step 1316 can be performed by executing a clock triggerDAG process. Step 1316 may be similar to step 1314. However, step 1316may be performed in response to a clock trigger rather than in responseto receiving a raw sample event. The clock trigger can periodicallytrigger step 1316 to perform batch queries (e.g., every hour). Step 1316may include identifying a timeseries ID specified in the clock triggerand accessing the timeseries collection to obtain the DAG for thecorresponding timeseries. Step 1316 may include identifying each deriveddata timeseries generated by the DAG and each operation included in theDAG. In some embodiments, step 1316 tags each operation to indicatewhether the operation should be sent to the C# engine 1332 or the Pythonengine 1334 for execution. Step 1316 may include identifying andfetching any additional data (e.g., samples, timeseries, parameters,etc.) which may be necessary to perform the operations defined by theDAG. Step 1316 may generate an enriched DAG which includes the originalDAG along with all the data necessary to perform the operations definedby the DAG. The enriched DAG can be sent to the DAG event hub 1318.

DAG event hub 1318 can be configured to store enriched DAG events. Eachenriched DAG event can include an enriched DAG. The enriched DAG mayinclude a DAG for a particular timeseries along with all the datanecessary to perform the operations defined by the DAG. DAG event hub1318 can provide the enriched DAG events to step 1320.

Still referring to FIG. 13A, workflow 1300 is shown to include runningthe DAG (step 1320). Step 1320 can include accepting enriched DAG eventsfrom DAG event hub 1318 and running through the sequence of operationsdefined by the DAG. Workflow manager 622 can submit each operation inseries to execution engines 1330 and wait for results before submittingthe next operation. Execution engines 1330 may include a C# engine 1332,a Python engine 1334, or any other engine configured to perform theoperations defined by the DAG. In some embodiments, execution engines1330 include timeseries operators 606. When a given operation iscomplete, execution engines 1330 can provide the results of theoperation to workflow manager 622. Workflow manager 622 can use theresults of one or more operations as inputs for the next operation,along with any other inputs that are required to perform the operation.In some embodiments, the results of the operations are the derivedtimeseries samples. The derived timeseries samples can be provided toderived timeseries event hub 1322.

Derived timeseries event hub 1322 can be configured to store derivedtimeseries events. Each derived timeseries event may include a sample ofan derived timeseries. The derived timeseries may include the results ofthe operations performed by execution engines 1330. Derived timeseriesevent hub 1322 can provide the derived timeseries samples to step 1324.

Workflow 1300 is shown to include storing the derived timeseries samples(step 1324). Step 1324 can include accepting derived timeseries samplesfrom derived timeseries event hub 1322 and storing the derivedtimeseries samples in persistent storage (e.g., local storage 514,hosted storage 516). In some embodiments, step 1324 is deployed on Azureusing Azure Worker Roles. The worker role may generate requests at arate based on Y % of the capacity of the storage. For example, if thecapacity of the storage is 10,000 RU and Y % is 50% (e.g., 50% of thestorage throughput is reserved for raw sample writes), and each writetakes 5 RU, step 1324 may generate a total of 1,000 writes per second

$\left( {{i.e.},{\frac{10,000*50\%}{5} = {1,000}}} \right).$

Referring now to FIG. 13B, a flowchart of a process 1350 for obtainingand processing timeseries data is shown, according to an exemplaryembodiment. Process 1350 can be performed by workflow manager 622 incombination with other components of timeseries service 528. Process1350 is shown to include obtaining samples of a timeseries fromtimeseries storage (step 1352). Step 1352 may include obtaining raw datasamples and/or derived data samples via timeseries storage interface616. The samples of the timeseries may be obtained from local storage514, hosted storage 516, or received in real-time from a sensor or otherdevice that generates the samples. Step 1352 can include loading theentire timeseries or a subset of the samples of the timeseries intolocal memory. For example, some of the samples of the timeseries may bestored in local memory (e.g., past 48 hours) whereas the remainder ofthe samples of the timeseries can be stored in local storage 514 orhosted storage 516.

Process 1350 is shown to include handling a post-sample request (PSR)associated with the timeseries (step 1354). The PSR may be obtained froma PSR collection via timeseries storage interface 616. The PSR can beused to provide status updates to the user for a specific timeseries ID.In some embodiments, step 1354 includes receiving a PSR and determiningwhether the PSR contains more than one timeseries ID. In response to adetermination that the PSR contains more than one timeseries ID, step1354 may include breaking the PSR into multiple PSRs, each of which islimited to a single timeseries ID. The PSRs can be provided to PSR eventhub 1306 and stored as PSR events. Each PSR event may include a PSR forone timeseries ID. In some embodiments, each PSR event is stored in theform “TimeseriesID: Timestamp.”

Process 1350 is shown to include deduplicating samples of the timeseries(step 1356). Step 1356 may be performed by executing a deduplicationprocess. In some embodiments, the deduplication process includesaccepting PSR events from PSR event hub 1306 and splitting each PSR intoa list of samples. Step 1356 may include tagging each sample as a newsample, an updated sample, or a duplicate sample. New samples andupdated samples can be sent to raw samples event hub 1310, whereasduplicate samples may be discarded. In some embodiments, step 1356 isdeployed on Azure using Azure Worker Roles. Step 1356 can includechecking for duplicate samples in local storage 514 and hosted storage516 as well as the samples that are currently in raw samples event hub1310.

In some embodiments, the deduplication process in step 1356 removes allduplicate data samples such that only a single unique copy of each datasample remains. Removing all duplicate samples may ensure that aggregateoperations produce accurate aggregate values. In other embodiments, thededuplication process in step 1356 is configured to remove most, but notall, duplicate samples. For example, the deduplication process can beimplemented using a Bloom filter, which allows for the possibility offalse positives but not false negatives. In step 1356, a false positivecan be defined as a non-duplicate new or updated sample. Accordingly,some duplicates may be flagged as non-duplicate, which introduces thepossibility that some duplicate samples may not be properly identifiedand removed. The deduplicated samples can be sent to raw samples eventhub 1310.

Still referring to FIG. 13B, process 1350 is shown to includeidentifying one or more stored DAGs that use the timeseries as an input(step 1358). Step 1358 can include obtaining the stored DAGs viatimeseries via timeseries storage interface 616 and identifying therequired timeseries inputs of each DAG. For each DAG that uses thetimeseries as an input, process 1350 can identify the timeseriesprocessing operations defined by the DAG (step 1360). The timeseriesprocessing operations can include data cleansing operations, dataaggregation operations, timeseries adding operations, virtual pointcalculation operations, or any other type of operation that can beapplied to one or more input timeseries.

Process 1350 is shown to include identifying and obtaining samples ofany timeseries required to perform the timeseries processing operations(step 1362). The timeseries can be identified by inspecting the inputsrequired by each of the timeseries processing operations identified instep 1360. For example, DAG 1000 in FIG. 10A is shown to include both“Timeseries ID: 123” and “Timeseries ID: 456” as required inputs.Assuming that samples of the timeseries ID 123 are obtained in step1352, DAG 1000 can be identified in step 1358 as a DAG that uses thetimeseries ID 123 as an input. The timeseries identified in step 1362can include timeseries ID 123, timeseries ID 456, or any othertimeseries used as an input to DAG 1000. Step 1362 may includeidentifying and fetching any additional data (e.g., samples, timeseries,parameters, etc.) which may be necessary to perform the operationsdefined by the DAG.

In some embodiments, the samples obtained in step 1362 are based on thetimeseries processing operations defined by the DAG, as well as thetimestamps of the original samples obtained in step 1352. For example,the DAG may include a data aggregation operation that aggregates aplurality of data samples having timestamps within a given time window.The start time and end time of the time window may be defined by the DAGand the timeseries to which the DAG is applied. The DAG may define theduration of the time window over which the data aggregation operationwill be performed. For example, the DAG may define the aggregationoperation as an hourly aggregation (i.e., to produce an hourly datarollup timeseries), a daily aggregation (i.e., to produce a daily datarollup timeseries), a weekly aggregation (i.e., to produce a weekly datarollup timeseries), or any other aggregation duration. The position ofthe time window (e.g., a specific day, a specific week, etc.) over whichthe aggregation is performed may be defined by the timestamps of thesamples obtained in step 1352.

Step 1362 can include using the DAG to identify the duration of the timewindow (e.g., an hour, a day, a week, etc.) over which the dataaggregation operation will be performed. Step 1362 can include using thetimestamps of the data samples obtained in step 1352 identify thelocation of the time window (i.e., the start time and the end time).Step 1362 can include setting the start time and end time of the timewindow such that the time window has the identified duration andincludes the timestamps of the data samples obtained in step 1352. Insome embodiments, the time windows are fixed, having predefined starttimes and end times (e.g., the beginning and end of each hour, day,week, etc.). In other embodiments, the time windows may be sliding timewindows, having start times and end times that depend on the timestampsof the data samples in the input timeseries. Once the appropriate timewindow has been set and the other input timeseries are identified, step1362 can obtain samples of any input timeseries to the DAG that havetimestamps within the appropriate time window. The input timeseries caninclude the original timeseries identified in step 1352 and any othertimeseries used as input to the DAG.

Process 1350 is shown to include generating an enriched DAG includingthe original DAG and all timeseries samples required to perform thetimeseries processing operations (step 1364). The original DAG may bethe DAG identified in step 1358. The timeseries samples required toperform the timeseries processing operations may include any of thetimeseries samples obtained in step 1362. In some embodiments, step 1364includes identifying each derived data timeseries generated by the DAGand each operation included in the DAG. In some embodiments, step 1364tags each operation to indicate a particular execution engine (e.g., C#engine 1332, Python engine 1334, etc.) to which the processing operationshould be sent for execution.

Process 1350 is shown to include executing the enriched DAG to generateone or more derived timeseries (step 1366). Step 1366 can includesubmitting each timeseries processing operation in series to executionengines 1330 and waiting for results before submitting the nextoperation. When a given operation is complete, execution engines 1330can provide the results of the operation to workflow manager 622.Process 1350 can use the results of one or more operations as inputs forthe next operation, along with any other inputs that are required toperform the operation. In some embodiments, the results of theoperations are the derived timeseries samples.

Process 1350 is shown to include storing the derived timeseries in thetimeseries storage (step 1368). The derived timeseries may include theresults of the operations performed in step 1366. Step 1368 can includeaccepting derived timeseries samples from derived timeseries event hub1322 and storing the derived timeseries samples in persistent storage(e.g., local storage 514, hosted storage 516). In some embodiments, step1368 is deployed on Azure using Azure Worker Roles. The worker role maygenerate requests at a rate based on Y % of the capacity of the storage.For example, if the capacity of the storage is 10,000 RU and Y % is 50%(e.g., 50% of the storage throughput is reserved for raw sample writes),and each write takes 5 RU, step 1368 may generate a total of 1,000writes per second

$\left( {{i.e.},{\frac{10,000*50\%}{5} = {1,000}}} \right).$Unified Management and Processing of Data in a Building ManagementInternet-of-Things (IoT) Environment

Data produced and generated by the devices within a BMS can be providedin multiple formats. As technology has changed over time, much of thedata produced and generated within the BMS system may be thought of asbeing essentially multi-media by nature, consisting primarily oftelemetry data, meta-data, acoustic signals (e.g. ultrasound), images,video and audio data, as well as text and mathematical notations. Insome examples, textual, audio, or video based annotations may beincorporated to allow for specific BMS data to be tagged to provideadditional information related to the BMS data. In an IoT based system,as described below, analysis, classification and indexing of IoT datacan depend significantly on the ability of the system to recognize therelevant information in multiple data streams, and fuse the recognizeddata. Fusing the recognized data may transform the collective semanticsof the individual data received from multiple devices into semanticsconsistent with the perception of the real world. However, fusion of therecognized information is difficult between different media and datatypes. Accordingly, a multi-modal data management system is describedbelow. The multi-modal data management system can provide flexible dataprocessing approaches to maximize information sharing between devices,and to allow for better actionable decision using the fused information.In one specific example, the multi-modal data management system can beconfigured to apply to unifying event/time series data, such as thosedescribed above.

FIG. 14 is a block diagram illustrating a silo configured IoTenvironment 1400, according to some embodiments. The IoT environment mayinclude a plurality of devices 1402, 1404, 1406, a cloud-based service1408, and a remote device 1410. While only three devices 1402, 1404,1406 are shown in FIG. 14, it is contemplated that the silo configuredIoT environment 1400 may include more than three devices or fewer thanthree devices, as needed. The devices 1402, 1404, 1406 may be any typeof BMS device, such as those described above. For example, the devices1402, 1404, 1406 can be sensors, controllers, actuators, sub-systems,thermostats, or any other component within the BMS system capable ofcommunicating to the cloud-based service 1408. In one embodiments, thedevices 1402, 1404, 1406 may be connected directly to the cloud-basedservice 1408 via an internet-based connection. For example, the devices1402, 1404, 1406 may be connected to the cloud-based service 1408 via awireless connection such as Wi-Fi. In some embodiments, the devices1402, 1404, 1406 are connected to the Internet via one or more gateways,routers, modems, or other internet connected devices, which providecommunication to and from the internet. In some examples, the devices1402, 1404, 1406 may be configured to communicate directly to theinternet. The devices 1402, 1404, 1406 may include wirelesstransmitters, such as cellular transmitters (3G, 4G, LTE, CDMA, etc.),that allow the devices 1402, 1404, 1406 to connect to the internetdirectly via one or more service providers.

As shown in FIG. 14, the devices communicate directly to the cloud-basedservice 1408. The cloud-based service 1408 may be one or more servicesprovided by a remote server (e.g. the cloud). In one embodiment, thecloud-based service can be a unified management and processing service,as will be described in more detail below. In other embodiments, thecloud-based service 1408 may be a timeseries service, as describedabove. The remote device 1410 may be one or more devices configured toaccess the cloud-based service 1408. In one of the embodiments, theremote device 1410 is a remote computer, such as a Personal Computer(PC). In other embodiments, the remote device 1410 is a mobile devicesuch as a smartphone (Apple iPhone, Android Phone, Windows Phone, etc.),a tablet computer (Apple iPad, Microsoft Surface, Android tablet, etc.).In still further embodiments, the remote device 1410 may be a dedicateddevice, such as a commissioning tool. In one embodiment, the remotedevice 1410 is configured to communicate with the one or more cloudbased services 1408. The remote device 1410 may be configured to allow auser to access the cloud-based services 1408. In some embodiments, auser may be able to request certain actions be performed from thecloud-based service 1408 via the remote device. For example, the remotedevice 1410 may be used to request certain reports and/or other dataprocessed by the cloud-based services. In other embodiments, the remotedevice 1410 may be used to request information relating to one or moreof the devices 1402, 1404, 1406 for analysis by the user. The remotedevice 1410 may be configured to access any functions of the cloud-basedservice 1408, for which the remote device 1410 has sufficientpermissions.

FIG. 15 is a block diagram illustrating a de-centralized IoT environment1500, according to some embodiments. Similar to environment 1400described above, the environment 1500 includes a number of devices 1502,1504, 1506. In one embodiment, the devices 1502, 1504, 1506 are similarto devices 1402, 1404, 1406, described above. The environment 1500 mayfurther include a cloud-based service 1508 and a remote device 1510. Thecloud-based service 1508 and the remote device 1510 may function ascloud-based service 1408 and remote device 1410 described above. Theenvironment 1500 is further shown to include a collator 1512.

The devices 1502, 1504, 1506 may be configured to communicate betweeneach other, or to the cloud-based service 1508 via the collator 1512. Inone embodiment, the devices 1502, 1504, 1506 are configured tocommunicate with each other over a network, such as BACnet. However,other networks, such as local-area-networks (LAN), wide-area networks(WAN), TCP/IP or other networks are also included. In some embodiments,the devices 1502, 1504, 1506 may communicate with each other via awireless protocol, such as Wi-Fi, LoRa, Cellular (3G, 4G, CDMA, LTE),Wi-Max, Bluetooth, Zigbee, etc. The devices 1502, 1504, 1506 may includeone or more processors, such as a microprocessor capable of processinginstructions. The devices 1502, 1504, 1506 may be configured to processdata within each device 1502, 1504, 1506. The devices 1502, 1504, 1506may further be configured to receive one or more instructions from thecloud-based service 1508. For example, the cloud-based service 1508 mayinstruct the devices 1502, 1504, 1506 to perform certain actions, or toprovide specific data to the cloud-based service 1508. In someembodiments, the devices 1502, 1504, 1506 may receive the requests fromthe cloud-based service and communicate with each other to provide therequested service.

In some embodiments, the devices 1502, 1504, 1506 communicate with thecloud-based service 1508 via the collator 1512. The collator 1512 isconfigured to provide coordination between the devices 1502, 1504, 1506.In some embodiments, the collator 1512 may be a software element withina local device, such as an internet gateway (not shown). In otherembodiments, the collator 1512 may be a service within the cloud-basedservices 1508. The collator 1512 may be configured to facilitate Edgecomputing between the devices 1502, 1504, 1506. For example, thecollator 1512 may be configured to coordinate between the device 1502,1504, 1506 to provide instructions to facilitate Edge computing (e.g.peer to peer or mesh computing). Further, the collator 1512 may serve toorganize data received from multiple devices 1502, 1504, 1506. Forexample, the collator 15012 may be configured to provide the unifiedmanagement and processing of IoT data described below.

Turning now to FIG. 16, a block diagram illustrating a multi-modal dataprocessing service 1600 is shown, according to some embodiments. Themulti-modal data processing service 1600 includes a timeseriesmicroservice API 1602, a processing layer 1604 and a storage layer 1606.The timeseries microservice API 1602 may provide an interface betweenone or more devices, databases, controllers, or other source of data viathe API. The timeseries microservice API 1602 may handle queriesprovided to the multi-modal data processing service 1600, which are thenserved directly from the storage layer 1606, ensuring low round-triptime (RTT). In some embodiments, the timeseries microservice API 1602may route data to the proper layer within the multi-modal dataprocessing service 1600 based on the type of data received. For example,telemetry data, or other data received from sensors or other devices maybe routed to the processing layer 1604. In other examples, previouslystored data, such as data received from databases or other data storagetypes may be provided to the storage layer 1606. In one embodiment, thepreviously stored data, or data reads, may be provided to the timeseriesstorage service API 1608 for processing into the storage layer 1606. Inone embodiment, the timeseries storage service API 1608 is configured toparse the data reads to determine how the data reads should be storedwithin the storage layer 1606.

The storage layer 1606 may be configured to store multiple data types.In one embodiment, the storage layer 1606 includes a multi-modal datastore 1610. The multi-modal data store 1610 may store the differentmulti-modal data types. For example, the multi-modal data store 1610 mayinclude a document store 1612, a column store 1614, a relational store1616 and an events store 1618. In some examples, the multi-modal datastore 1610 may also include in-memory cache for quickly accessing recentitems stored in a memory associated with the storage layer 1606 and/orthe multi-modal data processing service 1600. The data associated withthe document store 1612, the column store 1614, the relational store1616 and the events store 1618 will be described in more detail below.

The processing layer 1604 may be configured to process one or more datamessages 1620 received by the multi-modal data processing service 1600.data messages 1620 can include telemetry data from one or more sources,such as sensors, controllers, or other devices. The processing layer1604 may receive one or more data messages 1620. The data messages 1620may be unpacked at process element 1622. In one embodiment, the unpackeddata is pushed to the storage layer 1606. The storage layer 1606 mayanalyze the unpacked data to determine if additional information may berequired to process the data message 1620. The additional informationmay include metadata (e.g. device type, age, etc.), historical contenttags (prior incidents of faults, service history, etc.) as well as thedefinitions of data aggregation and transformation operations that needto be performed on the data message 1620 for generating analytics. Thedefinitions of data aggregation and transformation operations mayinclude cleansing, filling, aggregations, windowing operations, etc.).The additional data may be accessed from the multi-modal data store1610. In one example, the additional data may be accessed from themulti-modal data store 1610 via the in-memory cache.

The data message 1620 is then combined with the additional informationprovided via the multi-modal data store 1610 to form enriched datamessage 1624. In one embodiment, the additional information is combinedwith the data message 1620 at processing element 1626. The processinglayer 1604 may further include a processing service API 1628 and amulti-modal processing stack 1630. The processing service API 1628 isconfigured to access one or more processing engines within themulti-modal processing stack 1630 to allow for the enriched data message1624 to be processes. Example processing engines may include DotNet/C#engines, Python engines, SparkSQL engines, GraphX Engines, MLlibEngines, MATLAB engines, etc. The multi-modal processing stack 1630 isconfigured to perform the required operations to process the enricheddata message 1624. The multi-modal processing stack 1630 may further beable to generate metrics, such as transformed timeseries data, and otheranalytics. For example, the analytics may determine that a piece ofequipment may be at a high risk of a safety shutdown within the next 24hours. The metrics and analytics may then be stored in the storage layer1606.

The multi-modal data processing service 1600 is configured to manage andprocess heterogeneous data types and data models associated with an IoTenvironment. Example data types and data models may include timeseriesdata, 3D design data, graphical data, structure, unstructured, and/orsemi-structured data, video data, audio data, and the like. FIG. 17illustrates an example of multi-modal information related to a buildingchiller system, and specifically to a predictive maintenance applicationrelated thereto. While the following examples, are described in relationto a chilling system and a predictive maintenance application, it iscontemplated that the multi-modal data processing service 1600 iscompatible with other equipment within a BMS, as well as non-BMS relatedequipment. The multi-modal data processing service 1600 is furthercompatible with other applications. Accordingly, the following examplesare not intended to be limiting to a specific implementation. As statedabove FIG. 17 is an example user-interface 1700 providing a view ofmulti-modal data. The user-interface 1700 can be a highly efficient toolfor providing information to users, allowing then to better understandcausalities of events collected from various sensors or other datainputs within the BMS. For example, as it relates to a chilling system,the user-interface 1700 may include events collected from varioussensors related to the chilling system, applications including servicelogs (e.g., technician notes), vibration analysis, oil analysis,cameras, ultrasound sensors, thermometers, weather stations, or otherdata inputs related to the chilling system. In one embodiment, theuser-interface 1700 is generated by the multi-modal data processingservice 1600. In other embodiments, the user-interface 1700 may begenerated by a cloud service, such as those described above, and viewedusing a remote device.

The user-interface 1700 can include an equipment data portion 1702. Theequipment data portion 1702 can provide information related to the pieceof equipment being evaluated. Equipment data may include equipment name,location, operating status, network address, and the like. Theuser-interface 1700 can further include a time period portion 1704. Thetime period portion 1704 may be a user selectable time frame from whichto view various data types and values related to the equipment. In oneembodiment, the time period portion 1704 may reflect a set time length(e.g. ten minutes, one hour, one day, etc.). In other embodiments, thetime period portion 1704 may be configured to display a certain timeperiod. For example, a time period between one time (e.g. 12:00 AM) anda second time (e.g. 12:00 PM). In some examples, the time period portion1704 can be configured to reflect any time frame requested by the user.In one embodiment, the time period portion 1704 is associated with afailure, repair, or other event associated with the associated equipmentor system.

The user-interface 1700 may further be configured to display one or moremulti-modal data points with respect to the time period portion 1704.For example, the user-interface 1700 is shown to display technicianimages of components 1706, a vibration analysis 1708, an ultrasoundanalysis 1710, a technician note 1712 and telemetry data 1714. Thetechnician images of components 1706 may be images of components thathave experienced a failure, either recently or in the past. Thetechnician images of components 1706 may include image files such as.jpeg, .gif, .raw, .bmp, or other applicable image files. In otherexamples, the technician images of components 1706 may be video files.The vibration analysis 1708 may be an audio file, such as .mp3, .wav,.aiff, .wma, or the like. The vibration analysis 1708 may also include avisual representation of the audio file, such as a spectrum analysis forillustrating specific frequencies detected during the vibrationanalysis. The ultrasound analysis 1710 may include an audio file or animage file to illustrate the results of the ultrasound analysis 1710. Insome embodiments, the ultrasound analysis 1710 may include data in atabular format, such as in a .csv, or .xls file for export andmanipulation by a user. The technician note 1712 may be a textual note,or an audio note. In some embodiments, the technician note 1712 may bean annotated image or other file type. The telemetry data 1714 may bepresent for one or more sensors associated with the equipment. In someembodiments, the telemetry data is presented in a visual form, such asthe graph shown in FIG. 16. However, in other embodiments, the telemetrydata may be provided in other forms, such as via a spreadsheet (e.g..csv, .xls). The above examples are exemplary only, and it iscontemplated that the user-interface 1700 can display multiple differenttypes of multi-modal data, as relevant for a particular piece ofequipment.

Each of the images of components 1706, the vibration analysis 1708, theultrasound analysis 1710, the technician note 1712 and the telemetrydata 1714 have one or more reference points on the time period portion1704. For example, the telemetry data 1714 shows telemetry dataassociated with the entire time period displayed on the time periodportion 1704, while the other multi-modal data items have discretepoints on the time period portion 1704. For example, the technicianimages of components 1706 are associated with a discrete time, while theultrasound analysis 1710 is associated with a second time. Thus, theuser-interface 1700 provides a unified timeline visualization offailure, repair and operation, failure and other related events, and atelemetry data stream to a user, in this example. By unifying multipledata points and types associated with a piece of equipment of a system,an accurate and detailed history of one or more attributes of theequipment or system can easily be presented to a user for analysis.

This multitude of varied data types and data models can introduce a setof challenges as it relates to storing and indexing the varied datatypes and data models to provide a comprehensive view as shown inuser-interface 1700. In one embodiment, multi-modal data processingservice 1600 may be configured to use a polyglot persistence approach toprocessing the data, which allows for the storage of heterogeneous datatypes and other data models using multiple data storage technologies.The multiple storage technologies chosen based upon the way data isbeing used by individual applications or components of a singleapplication. Using polyglot persistence, the multi-modal data processingservice 1600 is responsible for providing Atomicity, Consistency,Isolation, and Durability (ACID) among different data models andstorages.

Turning now to FIG. 18, a block diagram illustrating an IoT applicationstorage topology 1800 is shown, according to some embodiments. The IoTapplication storage topology 1800 may include multiple storagetechnologies for use with polyglot persistence methods, described above.The iot application storage topology 1800 may include document storage1802, events storage 1804, entity relationship storage 1806, and reportstorage 1808. The document storage 1802 may include a document database1810. The document database 1810 can be used to store completed servicehistories, and maintenance records, as well as static and dynamicrelationships among entities including owner information, locations,asset details, and other maintenance recommendations.

The events storage 1804 can include a key value store 1812. The keyvalue store 1812 can be used to store maintenance and repair events, aswell as service recommendations (e.g. result of predictive analytics).The entity relationship storage 1806 may include a graph store 1814. Thegraph store 1814 may include results of predictive analytics performedby the multi-modal data processing service 1600. For example, the graphstore 1814 may include model results of the predictive analytic data.The reports storage 1808 may include a relational database 1816. Withinan application, such as the exemplary predictive maintenance applicationdescribed above, application data can be modeled with JavaScript ObjectNotation (JSON) like semi-structured objects or structured entities thatcan be efficiently stored and queried within one or more relationaldatabases 1816. Example, data stored within the relational databases1816 may include descriptions of installed locations of an asset, ownerinformation details, product specifications, firmware versions,telemetry data points, etc. In one embodiment, the document database1810, the key value stores 1812, the graph store 1814 and the relationaldatabase 1816 are stored in the multi-modal data store 1610 of themulti-modal data processing service 1600. In other embodiments, one ormore of the document database 1810, the key value stores 1812, the graphstore 1814 and the relational database 1816 are located in a cloud, suchas cloud-based services 1408, 1508.

As the multi-modal data processing service 1600 learns and discoversmore about relationships between events and entities, the multi-modaldata processing service 1600 is configured to consistently introduce newrelationships, and update or delete existing relationships throughanalytics services, (i.e., enriching semantic relationships). Forexample, a newly added maintenance event may lower a future failure modeof an asset by updating a causal relationship between the asset and afailure type. A set of recommended maintenance services (e.g. a set ofentities) can be introduced to an asset by creating or updating arelationship between an asset and a service.

Data Models for a Predictive Maintenance Application

Returning now to the predictive maintenance example, the multi-modaldata processing service 1600 may model the chiller with a digital twinthat is a virtual representation of a physical device, there the digitaltwin is a computerized companion of the physical device (e.g. thechiller system for purposes of this example). The digital twin may be a3D cad model with product specifications, or a set of telemetry datapoints associated to the physical device. In one embodiment, the datamodel representing the digital twin is a document (e.g., a JSON-baseddocument), that can be managed via document database 1810. In oneembodiment, the document database 1810 may manage the documents usingdocument stores such as MongoDB or DocumentDB. In some embodiments, themulti-modal data processing service 1600 may include a back-end serviceto ensure state consistency between a physical device and a device twin.The entity relationship storage 1806 may include a set of applicationspecific or business data, including a location of an asset, a productoperating specification, an owner information of assets, anorganizational hierarchy of assets, service provider details, and/orother information required to perform predictive field services. In someexamples, entity relationship modeling is useful where entities can bestored in a relational database (e.g. relational database 1816) or adocument database (e.g. document database 1810) where semantics betweenentities must be handled by an application. Graph databases, such asgraph store 1814 may also be used to model dynamic relationships betweenentities.

Data Management in a Predictive Maintenance Application

A connected device, such as a chiller, generates many different types ofstreaming data, including sensor readings, click streams, etc. Thus,data management and processing are an essential part of an IoT system.As described above, a variety of data types may be presented to themulti-modal data processing service 1600 in a predictive maintenanceapplication (or other relevant application). For example, every serviceevent can generate relevant data for future operational optimizations.For example, maintenance service events can include various multimediadata points, including textual reports on oil analysis (e.g. .pdf, .doc,or other document type), raw vibrational data, images of failedcomponents, 3D models of the device and repair parts, technician servicenotes, ultrasound data, and the like. In one example, a picture of adegraded component can be uploaded to one or more cloud services for acondition assessment. For example, the cloud service may be an advancedimage analysis service. If a replacement part is determined to berequired, the cloud service will place a replacement part order and awork order. In one embodiment, the cloud service is one or more serviceaccessed by the multi-modal processing stack 1630. In other embodiments,the multi-modal data processing service 1600 is the cloud serviceresponsible for coordinating the analysis.

Turning now to FIG. 19, a block diagram illustrating of a data scheme1900 associated with a piece of equipment 1902, such as chiller isshown, according to some embodiments. The equipment 1902 may have anumber of associated data points associated with the equipment 1902. Forexample, the equipment 1902 may be associated with maintenance logs1904, service histories 1906, reliability analysis 1908, productmanuals/specifications 1910, telemetry data 1912, device shadows 1914,service parts 1916, building/installation profiles 1918, user profiles1920, or other data points. The data points may include multiple datatypes, as described below in Table 1.

TABLE 1 Multimedia Data Types and Associated Usage Examples Data TypeUsage Example Image Picture of faulty parts, asset image, conditionaudit PDF/Scanned Document Product specifications, manual, servicehistory Unstructured Text service note, customer's problem descriptionStructured/Semi-structured Application metadata, user profile, businesstransaction data, etc. Time series, events Vibration analysis, faults,sensor readings, safety alerts, etc. Video Repair sequence instructions,operating instructions, etc. Audio Mechanical rotating device operatingsamples, operating environment noise, etc.

The data points shown in FIG. 19 may also provide various metadatapoints to the multi-modal data processing service 1600. Example metadatamay include data capture locations, author, time of capture, targetasset, etc. The metadata points provide contextual content for analysisand data processing of the multi-modal data. The above data points andassociated metadata may be stored in storage layer 1606 of themulti-modal data processing service 1600, or other databases accessibleby the multi-modal data processing service 1600. For example, the datapoints and metadata may be stored using blob storage, files systems,databases, etc.

The multi-modal data processing service 1600 may be configured to store,index and query various data models described above, includingdocuments, graphs, and events. In one embodiment, the multi-modal dataprocessing service 1600 accesses a predictive maintenance analyticservice to provide a predictive maintenance analysis. The predictivemaintenance analytic service may be accessed via the processing serviceAPI 1628. In one embodiment, the predictive maintenance analytic serviceaccess one or more multi-modal data stores within the multi-modal datastore 1610. The predictive maintenance analytic service may access thestores to find all relevant measurement identifiers to a target asset,timeseries data, and events to create a data frame for analysis. In someexamples, the telemetry data is stored in a timeseries store, which mayutilize different storage technology.

The predictive maintenance analytic service may apply predictive failureanalytics (e.g., matched potential failures and service recommendations.The predictive maintenance analytic service may further examine one ormore data frames to determine when an asset may failed. The predictivemaintenance analytic service may generate tagged events and update assetcondition attributes illustrating high risks of failure of assets. Thepredictive maintenance analytic service may provide persisting analyticoutcomes into a separate timeseries stream and add or update a tag in anentity to allow for more efficient future causality analysis.

Unified Data Management and Processing

As described above, the multi-modal data processing service 1600 mayutilize polyglot persistence topologies to generate mapping between datapoints and types to provide strong consistency of data stored in twodifferent data store. Specifically, polyglot persistence topology isused to map data between entity stores and telemetry data stores.Turning now to FIG. 20, a data map 2000 illustrating data mappingbetween entity/document stores and streamed data (e.g. telemetry data)stores, according to some embodiments. FIG. 20 has an application layer2002. The application layer 2002 may be configured to map data between adocument store/event store/graph store 2004 and a columnar store 2006(e.g., time series store). The application layer 2002 may utilize one ormore identifiers 2008 associated with data points within the documentstore/event store/graph store 2004, and one or more identifiers 2010associated with data points within the columnar store 2006, to map datapoints in the document store/event store/graph store 2004 to thecolumnar store 2006. The application layer 2002 is further responsiblefor maintaining ACID properties between the different storagetechnologies (e.g. the document store/event store/graph store 2004 andthe columnar store 2006).

The mapping used in FIG. 20 can require maintaining mappings andbuilding custom ACID services for each application, which can beexpensive and tedious to maintain. These issues can be resolved bybuilding a set of abstractions that provide APIs for applicationdevelopers and data management applications. For example, a referencearchitecture 2100 is shown in FIG. 21. The architecture 2100 may allowvarious data storage technologies to be abstracted using storage I/Oabstraction that provides consistent Create, Read, Update and Delete(CRUD) operations across multiple storage technologies. The architecture2100 may include an application layer 2102. The application layer 2102can provide an API for accessing the architecture 2100. The architecturemay further include a knowledge management module 2104, an ACIDmanagement module 2106, an entity management module 2108, a multimediadata and stream management module 2110, an analytic services module2112, a database/storage/IO Abstraction module 2114, a relationaldatabase management systems (RDBMS) module 2116, a document store 2118,a column-oriented storage 2120, a key-value module 2122, a graph store2124 and a file and blob storage 2126. The architecture 2100 may furtherinclude a security module 2128 for providing various security functionsto the architecture 2100. Finally, the architecture may include amanagement module for managing the various elements of the architecture,described above.

The knowledge management module 2104 is configured to store and maintainvarious knowledge based elements associated with a system or a device.The ACID management module 2106 is configured to maintain consistencyamong entities, attributes of entities, events, and/or telemetry data.The ACID management module 2106 is further configured to triggerconsistency check services when certain data changes are determined, andto make updates to other storages (e.g., foreign key relationships amongdifferent data store), such as document store 2118, column-orientedstorage 2120, key-value store 2122, graph store 2124, and file and blobstorage 2126. The entity management module 2108 provides master dataservice on stored entities and unified CRUD operations via storageabstraction APIs. The multimedia data & stream management 2110 providessimilar functionality of the entity management module 2108 and alsoprocesses various media types, blobs and files. The analytic servicesmodule 2112 is configured to provide timeseries analysis, imageanalysis, and other IoT data processing services. Thedatabase/storage/io abstraction module 2114 can manage the data storedwithin the various storage modules, as well as the underlying I/Oabstractions relating to what data received from a device or system isassociated with which storage module. The architecture 2100 removes theneed to maintain mappings, and the requirements to interact with variouslow-level storage interfaces.

Turning now to FIG. 22, a flow chart illustrating a process 2200 forperforming unified stream processing is shown, according to someembodiments. In one embodiment, the process 2200 is performed using themulti-modal data processing service 1600. However, other cloud-basedservices may also perform process 2200. At process block 2202, telemetrydata is received by a service, such as the multi-modal data processingservice 1600. In one embodiment, the telemetry data is provided by oneor more sensors associated with a system or individual equipment. Insome embodiments, the service receives all telemetry data in real time.In other embodiments, the service receives the telemetry dataperiodically. In one embodiment, the telemetry data is received by theservice via one or more APIs.

At process block 2204, the data message is unpacked. Unpacking the datamessage may include extracting all data types from the data message. Forexample, the telemetry data may be extracted, along with any metadataassociated with the telemetry data. Once the data is unpacked, theunpacked data is transmitted to the storage services at process block2208. Storage services may include the multi-modal data stores 1610,described above. The storage services then examine the unpacked to datato determine what, if any, additional data is required to process themessage at process block 2208. Additional data may include metadata(e.g. equipment type, age, etc.), historical content tags (e.g. priorincidents of faults, service history, etc.) as well as the definitionsof data aggregation and transformation operations that need to beperformed on the data to generate analytics (e.g. cleansing, filling,aggregations, windowing operations, etc.).

Once the additional data has been determined, the additional requireddata is fetched from one or more data stores (e.g. multi-modal datastore 1610) at process block 2210, and the data message is enriched withthe additional data at process block 2212. At process block 2214 theenriched data message is sent to one or more processing services to beprocessed. The processing services can perform the required operationsand generate metrics (e.g. transformed time series data) and analytics(e.g. tags indicating certain determined attributes of the equipment orsystem. In one embodiment, the processing services may be DotNet C#processing engines, python engines, SparkSQL engines, GraphX engines,MLlib engines, or he like.

Configuration of Exemplary Embodiments

The construction and arrangement of the systems and methods as shown inthe various exemplary embodiments are illustrative only. Although only afew embodiments have been described in detail in this disclosure, manymodifications are possible (e.g., variations in sizes, dimensions,structures, shapes and proportions of the various elements, values ofparameters, mounting arrangements, use of materials, colors,orientations, etc.). For example, the position of elements can bereversed or otherwise varied and the nature or number of discreteelements or positions can be altered or varied. Accordingly, all suchmodifications are intended to be included within the scope of thepresent disclosure. The order or sequence of any process or method stepscan be varied or re-sequenced according to alternative embodiments.Other substitutions, modifications, changes, and omissions can be madein the design, operating conditions and arrangement of the exemplaryembodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and programproducts on any machine-readable media for accomplishing variousoperations. The embodiments of the present disclosure can be implementedusing existing computer processors, or by a special purpose computerprocessor for an appropriate system, incorporated for this or anotherpurpose, or by a hardwired system. Embodiments within the scope of thepresent disclosure include program products comprising machine-readablemedia for carrying or having machine-executable instructions or datastructures stored thereon. Such machine-readable media can be anyavailable media that can be accessed by a general purpose or specialpurpose computer or other machine with a processor. By way of example,such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROMor other optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code in the form of machine-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer or other machine with a processor. Combinationsof the above are also included within the scope of machine-readablemedia. Machine-executable instructions include, for example,instructions and data which cause a general purpose computer, specialpurpose computer, or special purpose processing machines to perform acertain function or group of functions.

Although the figures show a specific order of method steps, the order ofthe steps may differ from what is depicted. Also two or more steps canbe performed concurrently or with partial concurrence. Such variationwill depend on the software and hardware systems chosen and on designerchoice. All such variations are within the scope of the disclosure.Likewise, software implementations could be accomplished with standardprogramming techniques with rule based logic and other logic toaccomplish the various connection steps, processing steps, comparisonsteps and decision steps.

What is claimed is:
 1. A timeseries management system comprising: one ormore computer-readable storage media having instructions stored thereonthat, when executed by one or more processors, cause the one or moreprocessors to: receive a raw data timeseries and a plurality of otherraw data timeseries, wherein each of the raw data timeseries and theplurality of other raw data timeseries are uniquely linked to onetimeseries processing workflow of a plurality of timeseries processingworkflows; identify an initial timeseries processing workflow of theplurality of timeseries processing workflows that is uniquely linked tothe raw data timeseries, the initial timeseries processing workflowcomprising a predefined sequence of timeseries processing operations;identify one or more other data timeseries for inputs to the initialtimeseries processing workflow; generate an enriched timeseriesprocessing workflow comprising the initial timeseries processingworkflow, the raw data timeseries, and the one or more other datatimeseries; and execute the enriched timeseries processing workflow togenerate one or more derived data timeseries from the raw datatimeseries and the one or more other data timeseries.
 2. The timeseriesmanagement system of claim 1, wherein the instructions cause the one ormore processors to: identify and obtain samples of the raw datatimeseries and the one or more other data timeseries required to performthe predefined sequence of timeseries processing operations; andgenerate the enriched timeseries processing workflow comprising thesamples of the raw data timeseries and the one or more other datatimeseries.
 3. The timeseries management system of claim 1, wherein theinstructions cause the one or more processors to execute each of thepredefined sequence of timeseries processing operations using anexecution engine.
 4. The timeseries management system of claim 1,wherein the instructions cause the one or more processors to: tag eachof the predefined timeseries processing operations in the enrichedtimeseries processing workflow with an indication of an executionengine; and execute each of the predefined sequence of timeseriesprocessing operations using the execution engine.
 5. The timeseriesmanagement system of claim 1, wherein the instructions cause the one ormore processors to: accept a post-sample request associated with the rawdata timeseries; and execute the post-sample request in response toobtaining one or more new samples of the raw data timeseries.
 6. Thetimeseries management system of claim 1, wherein the instructions causethe one or more processors to: determine a time window based on anaggregation period specified by the predefined sequence of timeseriesprocessing operations; and obtain samples of the raw data timeseries andthe one or more other data timeseries that have timestamps within thetime window.
 7. The timeseries management system of claim 6, wherein theinstructions cause the one or more processors to determine the timewindow based on the timestamp of the raw data samples and a duration ofthe aggregation period specified by the predefined sequence oftimeseries processing operations.
 8. The timeseries management system ofclaim 1, wherein the initial timeseries processing workflow comprises adirected acyclic graph representing the predefined sequence oftimeseries processing operations in the initial timeseries processingworkflow.
 9. The timeseries management system of claim 8, wherein thedirected acyclic graph comprises: one or more input blocks representingone or more input timeseries to which the initial timeseries processingworkflow applies; one or more functional blocks representing thepredefined sequence of timeseries processing operations in the initialtimeseries processing workflow; and one or more output blocksrepresenting one or more derived data timeseries generated by applyingthe predefined sequence of timeseries processing operations to the oneor more input timeseries.
 10. The timeseries management system of claim1, wherein the initial timeseries processing workflow comprises: anindication of one or more input timeseries to which the initialtimeseries processing workflow applies; the predefined sequence oftimeseries processing operations; and an indication of one or morederived data timeseries generated by applying the predefined sequence oftimeseries processing operations to the one or more input timeseries.11. The timeseries management system of claim 10, wherein the predefinedsequence of timeseries processing operations is at least one of adynamically defined sequence of timeseries processing operations or astatic predefined sequence of timeseries processing operations.
 12. Thetimeseries management system of claim 10, wherein the one or more inputtimeseries comprise at least one of: the raw data timeseries; or the oneor more derived data timeseries.
 13. A method for managing timeseriesdata, the method comprising: receiving, by a processing circuit, a rawdata timeseries and a plurality of other raw data timeseries, whereineach of the raw data timeseries and the plurality of other raw datatimeseries are uniquely linked to one timeseries processing workflow ofa plurality of timeseries processing workflows; identifying, by theprocessing circuit, an initial timeseries processing workflow of theplurality of timeseries processing workflows that is uniquely linked tothe raw data timeseries, the initial timeseries processing workflowcomprising a predefined sequence of timeseries processing operations;identifying, by the processing circuit, one or more other datatimeseries for inputs to the initial timeseries processing workflow;generating, by the processing circuit, an enriched timeseries processingworkflow comprising the initial timeseries processing workflow, the rawdata timeseries, and the one or more other data timeseries; andexecuting, by the processing circuit, the enriched timeseries processingworkflow to generate one or more derived data timeseries from the rawdata timeseries and the one or more other data timeseries.
 14. Themethod of claim 13, comprising: identifying and obtaining, by theprocessing circuit, samples of the raw data timeseries and the one ormore other data timeseries required to perform the predefined sequencetimeseries processing operations; and generating, by the processingcircuit, the enriched timeseries processing workflow comprising thesamples of the raw data timeseries and the one or more other datatimeseries.
 15. The method of claim 13, comprising: tagging, by theprocessing circuit, each of the predefined sequence of timeseriesprocessing operations in the enriched timeseries processing workflowwith an indication of an execution engine; and executing, by theprocessing circuit, each timeseries processing operation using theexecution engine.
 16. The method of claim 13, comprising: accepting, bythe processing circuit, a post-sample request associated with the rawdata timeseries; and executing, by the processing circuit, thepost-sample request in response to obtaining one or more new samples ofthe raw data timeseries.
 17. The method of claim 13, wherein the initialtimeseries processing workflow comprises a directed acyclic graphvisually representing a predefined sequence of timeseries operations inthe initial timeseries processing workflow.
 18. The method of claim 13,wherein the initial timeseries processing workflow comprises: anindication of one or more input timeseries to which the initialtimeseries processing workflow applies; the predefined sequence oftimeseries processing operations; and an indication of one or morederived data timeseries generated by applying the predefined sequence oftimeseries processing operations to the one or more input timeseries.19. The method of claim 13, further comprising: determining, by theprocessing circuit, a time window based on an aggregation periodspecified by the predefined sequence of timeseries processingoperations; and obtaining, by the processing circuit, samples of the rawdata timeseries and the one or more other data timeseries that havetimestamps within the time window.
 20. A smart environment managementsystem comprising: one or more processors and a memory to storeinstructions, the instructions is executed by the one or more processorto: receive a raw data timeseries, wherein the raw data timeseries isuniquely linked to one timeseries processing workflow of a plurality oftimeseries processing workflows; identify the one timeseries processingworkflow of the plurality of timeseries processing workflows that islinked to the raw data timeseries, the one timeseries processingworkflow comprising a predefined sequence of timeseries processingoperations; identify one or more other data timeseries required asinputs to the one timeseries processing workflow; generate an enrichedtimeseries processing workflow comprising the one timeseries processingworkflow, the raw data timeseries, and the one or more other datatimeseries; and execute the enriched timeseries processing workflow togenerate one or more derived data timeseries from the raw datatimeseries and the one or more other data timeseries.